Шкаф управления вентиляцией связывает предусмотренные нагрузки, датчики и органы управления с алгоритмом установки. Его состав определяют по оборудованию, способам управления, режимам и защитам. Одной мощности вентилятора для задания недостаточно: нужно описать, какие команды выдаются, чем подтверждается их выполнение и что происходит при отказе.
Удобный результат подготовки — матрица «оборудование → сигнал → режим → ожидаемое поведение → проверка». Она помогает сопоставить проект, собранный шкаф и работу установки. Ниже рассмотрено составление такой матрицы, а не устройство приточки вообще. Примеры учебные; реальные последовательности и испытания задаются проектом, документацией изготовителей и принятой безопасной программой работ.
Сначала определите границы шкафа
В описи укажите, чем управляет шкаф и какие устройства остаются самостоятельными. Вентилятор может иметь собственный привод и защиту, установка — заводской контроллер, а отдельный узел нагрева — свой комплект автоматики. Без этой границы легко включить в задание функцию, которую уже выполняет другое устройство, или оставить её без исполнителя.
Нужны обозначение установки, модель, схема, состав секций и комплект доступной документации. Для существующего объекта важно различить паспортное исполнение и фактическую комплектацию после переделок. Расхождения отмечают отдельно, с указанием источника сведений.
Общий путь воздуха и функции узлов разобраны в статье приточная установка: состав и автоматика. Здесь этот список превращается в границы ответственности: что входит в шкаф, что подключается к нему и от какой внешней системы приходит разрешение или состояние.
Как описать нагрузки и способы управления
Для каждой нагрузки запишите модель, электрические данные по паспорту, способ пуска или регулирования и доступные сигналы. Двигатель с прямым пуском и вентилятор с регулирующим приводом требуют разных функций управления. Слово «вентилятор» не определяет ни состав силовой части, ни интерфейс команд.
Так же описывают приводы воздушных клапанов, насос водяного узла и предусмотренные ступени нагрева или охлаждения. Необходимо понимать, что принимает устройство: дискретную команду, аналоговое задание или данные по протоколу. Конкретные параметры подтверждаются по документации модели.
В руководстве Siemens по периферии контроллера POL224 разные виды датчиков и исполнительных устройств имеют свои интерфейсы. Это пример конкретного контроллера, а не универсальная схема вентиляционного шкафа. Его полезный смысл для задания: одинаковую функцию нельзя автоматически считать одинаковым электрическим сигналом на любом оборудовании.
Как собрать сигналы без двусмысленных названий
Начните с функции точки. «Пуск», «готовность», «работа» и «неисправность» — разные сведения. Если назвать их одной строкой «вентилятор», невозможно проверить, что приходит в контроллер и что увидит оператор.
| Узел | Команда или данные | Предусмотренное подтверждение | Отказ или ограничение | Источник сведений |
|---|---|---|---|---|
| Вентилятор с приводом | Запрос работы, задание регулирования | Доступные состояния привода | Готовность, код или общий сигнал отказа | Паспорт привода и схема |
| Воздушный клапан | Предусмотренная команда положения | Обратная связь, если установлена | Неподтверждённое положение | Документация привода |
| Датчик температуры | Измеренное значение | Качество и допустимый диапазон | Отказ или недоступность источника | Паспорт датчика и описание входа |
| Контроль фильтра | Состояние или измерение | Показание предусмотренного контроля | Событие обслуживания по алгоритму | Схема и метод оценки |
Это опись функций, а не обязательный набор входов и выходов. Протокольное устройство может передавать несколько параметров через одно соединение. Сигнал обратной связи, которого нет в комплектации, нельзя получить простым добавлением тега на экран.
Чем отличаются режимы установки
Для каждого режима укажите источник задания и допустимые действия пользователя. В автоматическом управлении запрос может приходить от расписания или верхнего уровня. При местном управлении роль выполняет предусмотренный орган на шкафу. Сервисный режим может иметь отдельные условия и доступ.
Название «ручной» неоднозначно. Оно может относиться к режиму всей установки, конкретному узлу или принудительно заданному значению в инженерном инструменте. Эти варианты не следует смешивать в ТЗ. Принудительное значение на наладке не становится штатным операторским режимом только потому, что оно называется manual.
Например, Systemair Access 5.x разделяет ручные воздействия на функции и ограничивает их назначение испытаниями и наладкой. Это поведение конкретной системы. Для своего шкафа опишите, как обозначается сервисное состояние, кто вправе его использовать и каким способом подтверждается возврат к принятому рабочему режиму.
Где задать приоритеты и защитные реакции
Одновременно могут существовать запрос расписания, местная команда, сообщение внешней системы и состояние защиты. Матрица режимов должна объяснять, какой сигнал определяет результат при такой комбинации. Если этого нет, каждый участник проекта может понимать слово «останов» по-своему.
Для внешних блокировок нужны источник, смысл состояния, требуемая реакция и условия восстановления. Отдельно описывают взаимодействие с пожарными системами по принятому проекту. Нельзя переносить правило «при пожаре всегда всё выключить» или обратное правило на любой объект.
В описании Fire/Smoke для Systemair Access предусмотрены разные режимы и отдельно указана необходимость соответствия местным требованиям. Этот пример показывает зависимость поведения от назначения установки. Он не является основанием назначать пожарные приоритеты, игнорирование защит или положения клапанов без проекта и проверки допустимости для оборудования.
Что должно быть видно на местной панели и в SCADA
Отображение строят по тем же обозначениям, что используются в схемах и перечне сигналов. Для установки нужны режим, доступное фактическое состояние и причина ограничения. Если команда приходит с верхнего уровня, оператору полезно видеть её источник и условия, при которых локальный контроллер её принимает.
На панели и в SCADA следует различать отказ оборудования и потерю связи с ним. Последнее сохранённое значение не доказывает текущую работу. Также нужно заранее определить, какие события остаются локальными, какие передаются наверх и где хранится их история.
В матрицу добавьте столбцы «местная панель» и «SCADA». Тогда отсутствие нужного сообщения станет видно до разработки экранов. Это особенно важно, когда шкаф и диспетчеризацию выполняют разные специалисты: каждый может считать, что другой уже предусмотрел отображение. Сам перечень данных ещё не задаёт расположение кнопок и права пользователя, поэтому эти вопросы проверяют отдельно.
Учебная матрица для одной установки
Представим вентиляционную установку с управляемым воздушным клапаном и вентилятором с приводом. В принятом учебном алгоритме есть запрос работы, подтверждение предусмотренной готовности и доступный сигнал состояния вентилятора. Таблица описывает смысл проверок; она не задаёт реальную пусковую последовательность или параметры задержек.
| Сценарий | Исходное условие модели | Ожидаемый результат | Что записать в протокол |
|---|---|---|---|
| Штатная работа | Условия разрешения подтверждены | Состояния согласованы с алгоритмом | Запрос, разрешение, фактическое подтверждение |
| Запрос при отсутствии готовности | Разрешающее условие не подтверждено | Понятная причина ограничения | Источник запрета и отображение |
| Нет подтверждения выполнения | Запрос есть, результата нет | Предусмотренная реакция и сообщение | Какие состояния сравнивает алгоритм |
| Потерян обмен с приводом | Данные недоступны | Отличимое состояние недостоверности | Поведение локального управления и экрана |
| Сервисный режим завершён | Выполнена процедура выхода | Возврат к принятому управлению | Отсутствие оставшихся тестовых воздействий |
Для испытаний на стенде могут использоваться модели сигналов. Это позволяет проверить логические переходы без воздействия на рабочую установку. Но такой протокол не доказывает физическое движение клапана или работу вентилятора: эти результаты требуют отдельного этапа приёмки.
Как разделить проверки шкафа и установки
До подключения проверьте соответствие комплектности, обозначений и документации принятому проекту. Схема, перечень сигналов и описание алгоритма должны говорить об одном оборудовании. При замене датчика или привода важно проверить не только его наличие, но и совместимость интерфейса и функций.
Стендовая проверка подтверждает поведение программы при заданных состояниях. На объекте отдельно подтверждают фактические источники сигналов и работу связки с оборудованием. Для датчика это может включать предусмотренное сравнение показания; для исполнительного механизма — доступное подтверждение его действия по программе работ.
Защитные и пожарные сценарии проверяют по согласованной безопасной методике с нужными ответственными специалистами. Искусственная авария на действующей установке не является допустимой заменой такой методики. В итоговом протоколе разделяют проверенные сценарии, стендовые имитации и оставшиеся ограничения. Подпись «все входы видны» не подтверждает, что установка правильно реагирует во всех режимах.
Какие материалы передать вместе со шкафом
Нужны актуальные схемы, опись оборудования, перечень сигналов, описание режимов и приоритетов, принятые версии проектов и результаты проверок. Для эксплуатации добавьте понятные сообщения и предусмотренные действия при типовых состояниях. При передаче резервных копий укажите, что они восстанавливают и чем проверена их актуальность.
Исходную таблицу можно подготовить на основе перечня сигналов для ИТП, КНС и вентиляции, добавив именно режимы, подтверждения и критерии приёмки своей установки. Это расширяет CSV рабочим смыслом, а не создаёт ещё один список названий датчиков.
Для обсуждения автоматизации вентиляции подготовьте модель установки, доступные паспорта и такую матрицу. По ней можно определить состав шкафа, разделить обязанности участников и заранее договориться, какими доказательствами будет подтверждён результат.
