Автоматизация котельной с шестью котлами: проект, монтаж и ПНР

Задача и границы нашей работы

Объект находится в Архангельской области. В состав котельной входят шесть газовых котлов, четыре насосные группы, станция водоснабжения, подпитка и два регулируемых контура.

Наша команда подготовила проект по разделу автоматизации, разработала программное обеспечение общекотельного контроллера и выполнила пусконаладочные работы. Изготовление шкафов, прокладку кабелей и монтаж оборудования выполнял строительный генподрядчик.

Архитектура общекотельной автоматики

Центральным узлом стал российский контроллер ОВЕН СПК210. Он управляет периферией котельной, рассчитывает необходимую тепловую мощность и координирует ввод шести котлов в каскад.

Обмен с локальными котловыми контроллерами ОВЕН КТР организован по Modbus RTU. В программу также вошли ротация оборудования, резервирование насосов, поддержание давления и регулирование двух температурных контуров.

• 6 газовых котлов и локальные контроллеры ОВЕН КТР
• ОВЕН СПК210 на общекотельном уровне
• 4 насосные группы с частотным регулированием
• Станция водоснабжения, подпитка и 2 контура

Почему систему нельзя сводить к одному контроллеру

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

Мы отстаивали разделение ответственности между общекотельным уровнем, котловой автоматикой и самостоятельными режимами оборудования. Для эксплуатации важна не только работа штатного алгоритма, но и возможность безопасно управлять узлом при отказе связи или центрального ПЛК.

Разрыв между проектом и исполнением

После передачи схем и спецификаций шкафы изготавливались и монтировались другой командой. При таком разделении разработчик программного обеспечения видит реальный результат только перед началом запуска.

На объекте обнаружились несоответствия, которые нельзя устранить изменением алгоритма: ошибки прокладки линий связи, недостаточная готовность отдельных цепей и отсутствие предусмотренных эксплуатацией локальных функций. Каждый такой дефект превращал ПНР в дополнительное обследование монтажа.

• Проект и фактический монтаж проверяют разные команды
• Изменения при сборке не всегда возвращаются в документацию
• Программист впервые видит шкаф непосредственно перед запуском
• Монтажные дефекты обнаруживаются уже во время ПНР

Modbus RTU, собранный звездой

Один из характерных примеров — линия связи с устройствами. Вместо последовательной шинной топологии участок был подключён звездой. В результате обмен с частью оборудования не работал стабильно.

До исправления физической линии программная диагностика не могла решить проблему. Пришлось локализовать участок, объяснить требуемую топологию и дождаться переделки монтажа. Это работа, которая при профильном монтаже проверяется до приезда инженера ПНР.

Насосы без независимого ручного управления

В шкафы насосных групп были заведены команды по Modbus, но не было реализовано удобное местное управление частотными преобразователями с переключателем режима и заданием скорости.

При недоступности центрального контроллера быстрый запуск насоса потребовал бы изменения настроек непосредственно на частотном преобразователе. Для данного объекта мы считаем более эксплуатационным решение, при котором ограниченный ручной режим предусмотрен схемой и заранее проверен.

Почему ПНР растягивается на недели

При подготовленном объекте первоначальный запуск такого объёма можно было бы провести за несколько рабочих дней: проверить обмен, каналы, механизмы, последовательности и затем настроить регуляторы.

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

• Поиск неисправного физического соединения
• Ожидание исправления монтажа
• Повторная проверка линии или механизма
• Только затем — проверка алгоритма и регулирования

Как проходит проект полного цикла

Когда проектирование, изготовление шкафов, программирование и монтаж находятся в одной инженерной цепочке, вопросы закрываются раньше. Сборочный цех проверяет цепи, маркировку, питание и связь до отправки оборудования на объект.

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

• Проектирование с учётом реальной эксплуатации
• Сборка шкафов с внутренней проверкой
• Монтаж специалистами по промышленной автоматизации
• ПНР как настройка технологии, а не исправление сборки

Что даёт внутренняя проверка шкафов

До отгрузки можно выполнить прозвонку цепей, проверить дискретные и аналоговые каналы, связь с частотными преобразователями и работу локальных органов управления. Параллельно программное обеспечение проверяется на доступном стенде.

Это не отменяет испытаний на объекте, но резко уменьшает количество неизвестных. Если при запуске температура выходит за требуемый график, инженер ищет причину в настройке процесса, а не начинает с проверки каждого соединения внутри шкафа.

• Прозвонка и маркировка цепей
• Проверка питания и сигналов ввода-вывода
• Тест промышленных сетей и локальных режимов
• Предварительная проверка программного обеспечения

Результат после устранения замечаний

После исправления монтажных несоответствий мы проверили обмен СПК210 с шестью котловыми контроллерами, четыре насосные группы, подпитку, станцию водоснабжения и регулирование двух контуров.

Котельная введена в эксплуатацию в феврале 2026 года. Автоматика рассчитывает требуемую мощность, управляет каскадом и поддерживает заданную температуру по графику. С момента запуска отказов системы не зафиксировано.

Главный инженерный вывод

Разделение работ между компаниями само по себе не является ошибкой. Проблемы начинаются, когда у участников разные критерии результата: один отвечает за минимальную стоимость монтажа, другой — за работоспособность программы, а целостность системы проявляется только на ПНР.

Поэтому мы предпочитаем вести АСУ ТП от концепции и проекта до сборки, монтажа и запуска. Это не стремление выполнить всё формально своими силами, а способ сохранить техническую логику на каждом этапе и отвечать перед заказчиком за конечный результат.