Открываешь тендер, и читаешь: «Закупка системы АСУ ТП». Звучит будто речь идёт о телевизоре или ноутбуке: вот он стоит на полке, бери и плати, но на самом деле это иллюзия. АСУ ТП нельзя просто «купить» - её нужно разрабатывать. И этот момент принципиально важен.
Даже в недавно обновлённом ГОСТе (ГОСТ Р 59793-2021 Автоматизированные системы. Стадии создания) прямо указано, что АСУ ТП - это всегда результат проектирования, согласования, тестирования и долгой эксплуатации. Это не товар, а услуга. И именно поэтому разрыв между ожиданиями заказчиков («дайте готовую систему сразу») и реальностью («надо пройти путь разработки») становится источником многих проблем..
🏷️Почему вообще в тендерах пишут «закупка АСУ ТП»?
Дело в том, что с точки зрения бухгалтерии и контрактов заказчик действительно что-то закупает. Деньги тратятся, поставщик определяется, договор подписывается. Однако АСУ ТП - это не готовый товар, а услуга. Система создаётся под конкретное производство, с учётом его процессов, оборудования, персонала, инфраструктуры и даже будущих задач развития. Именно поэтому ГОСТ прямо подчёркивает, что речь идёт не о покупке «коробки», а о разработке. А разработка - это путь, где результат формируется постепенно, шаг за шагом, через документацию, проектирование, испытания и доработки.
И вот тут часто возникает недопонимание. Заказчики хотят получить систему «под ключ» сразу и без проблем, а исполнители знают, что без поэтапного развития это невозможно.
📃Всё начинается с документации.
Любая АСУ ТП начинается не с кабелей и шкафов, а с бумаги. ГОСТ требует сначала собрать все сведения: что именно нужно автоматизировать, какие процессы должны управляться, какое оборудование будет задействовано, какие условия эксплуатации. Только после этого формируется проектная документация, в виде, требования к системе, спецификации, архитектуры.
Чтобы было нагляднее, ГОСТ делит работу на последовательные стадии:
1) Формирование требований к АС (обследование объекта, сбор пожеланий пользователей, обоснование необходимости создания системы)
2) Разработка концепции АС (изучение объекта, варианты концепций, оценка рисков, выбор оптимального решения)
3) Техническое задание (формализация и утверждение требований)
4) Эскизный и технический проект (предварительные и детализированные проектные решения)
5) Технический проект (разработка проектных решений по АС и ее частям)
6) Рабочая документация (разработка документов для конкретной реализации)
7) Ввод в действие (подготовка объекта и персонала, монтаж, испытания, опытная эксплуатация)
8) Сопровождение АС (гарантийное и послегарантийное обслуживание)
Т.е. первые 6 этапов из 8-и – только документы! Кстати, в «документацию» входит и разработка программного обеспечения АСУ ТП (разработка ПО в SCADA TRACE MODE и программирование контроллеров). Не будем забывать, что с точки зрения Закона, программа для ЭВМ – это литературное произведение (ГК РФ Статья 1261).
Важно понимать, что каждый этап документации - это шанс выявить ошибки ещё до того, как они обернутся дорогостоящими проблемами при внедрении. ГОСТ фактически закладывает модель постепенного «вызревания» проекта. Ошибки могут находиться и на старте, и в середине, и в конце пути. Исправлять их можно не сразу, т.к. система допускает корректировки на следующих этапах.
🌱Этапность и модель «вызревания».
Мы уже разобрались, что ГОСТ описывает разработку АСУ ТП как последовательность этапов, где каждый шаг имеет значение. Для простоты, это можно сравнить с выращиванием растения: сначала семя (документация), потом росток (проектирование), затем уход и подкормка (тесты, отладка) и, наконец, полноценный плод (система в эксплуатации). Тут главная идея в том, что ошибки на каждом этапе неизбежны и нормальны. Важно не то, чтобы их не было вовсе (так не бывает), а то, чтобы они постоянно выявлялись и исправлялись на следующих этапах. Здесь должна быть совместная работа между исполнителем и заказчиком, чем, зачастую, заказчик заниматься не хочет – «Сделай мне все красиво, а я потом буду принимать работу в целом».
Такой подход защищает проект от катастрофических провалов. Например, если недочёт обнаружен на этапе концепции, то его можно поправить в ходе реализации, если ошибка всплыла при внедрении, то её можно устранить в процессе опытной эксплуатации. Система постоянно адаптируется к реальности.
ГОСТ предполагает не одномоментное «создание готовой системы», а эволюцию. Система становится зрелой только тогда, когда проходит через все стадии: от замысла до практического использования.
👌Ошибки как часть процесса.
Многие заказчики боятся самого слова «ошибка». Кажется, что её наличие - это провал разработчика. Но в логике ГОСТа ошибки - это естественная и даже необходимая часть жизненного цикла системы. Когда АСУ ТП начинает работать «вживую», она сталкивается с реальностью: реальными ограничениями ИТ-инфраструктуры, практиками управления, с требованиями безопасности, с реальными помехами и отказами оборудования, ошибками технического задания и с непредсказуемыми ситуациями. И именно в этой практике обнаруживаются те недочёты, которые невозможно было предусмотреть на бумаге. Более того, сам ГОСТ закладывает интерактивность процесса. Это можно представить следующим образом:
• выявлять проблемы может не только разработчик, но и пользователи;
• ошибки фиксируются и постепенно устраняются;
• каждая корректировка повышает зрелость системы.
Значит получается, что АСУ ТП «созреет» только в процессе эксплуатации? ГОСТ Р 59793-2021 утверждает именно так – ошибки и недочеты выявляются как до приемочных испытаний, так и после них, на этапе постоянной эксплуатации, и даже после окончания гарантийного срока. В общем, совершенству предела нет…
Бумажный проект даёт основу, тесты проверяют гипотезы, но настоящий экзамен система сдаёт в цеху, на производстве. И это нормально. Живой опыт пользователей — это всегда главный двигатель совершенствования!
🏁Заключение.
АСУ ТП нельзя просто купить, как ноутбук в магазине. Это путь от документации и проектирования, до эксплуатации и постоянных доработок. ГОСТ Р 59793-2021 Автоматизированные системы. Стадии создания фиксирует именно этот живой, практический подход, в котором:
1) ошибки не страшны, они ожидаемы и полезны;
2) система становится зрелой только в процессе эксплуатации;
3) реальная работа и обратная связь пользователей делают её по-настоящему эффективной.
На практике идеал достигается лишь через взаимодействие, корректировки и опыт. И в этом нет слабости, а наоборот, это единственный способ создать систему, которая будет реально работать.
Так видит разработку ГОСТ. А как видите её вы?
__________________________________________________________________________________________
🔎Читайте также:
• Подписывайтесь на Telegram --> https://t.me/tracemode
• Внедрения SCADA TRACE MODE 7 --> https://tracemode.ru/apps/energetics
• Коротко о SCADA TRACE MODE 7 --> https://tracemode.ru/products/articles/obzor_TM7
• Начало работы в TRACE MODE 7 --> https://tracemode.ru/products/articles/scada_TM7_startup
• Самоучитель TRACE MODE 7 --> https://tracemode.ru/products/articles/TM7sam