Группа ФФУ становится проблемой управления задолго до того, как превращается в проблему воздушного потока. Как только агрегаты подключаются к шлюзу или системе управления зданием, перед проектом встает не вопрос “работает ли каждый агрегат?”, а вопрос: “знает ли система управления однозначно, какой агрегат какой, к какой зоне он относится и что происходит, когда возникает сбой?” Ошибки в этом вопросе обычно не выявляются во время ввода в эксплуатацию отдельного агрегата; они проявляются позже, когда сигнал тревоги указывает на местоположение, которое больше не соответствует фактической схеме, или когда команда для зоны поступает не той группе агрегатов.

Сопоставить каждый адрес FFU с физическим местоположением и зоной эксплуатации

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

Для сопоставления требуется как минимум четыре элемента, связанных с каждым адресом: физическое расположение устройства, зона эксплуатации, к которой оно относится, контроллер, которому оно подчиняется, и цепь питания, которая его питает. Каждый из этих факторов влияет на интерпретацию сигнала, поступающего от данного устройства. Сигнал о состоянии от устройства означает одно, если контекст зоны известен, и другое — если он неизвестен: сообщение о неисправности без указания контекста зоны сообщает оператору, что что-то не так, но не объясняет, что именно означает эта “неисправность” для процесса, который защищает данная зона. Аналогичным образом, знание цепи питания имеет важное значение, поскольку устройство, которое перестало подавать сигнал из-за неисправности в проводке, не должно диагностироваться или обрабатываться так же, как устройство, которое перестало подавать сигнал из-за проблем со связью, даже если с точки зрения чистого статуса оба случая могут выглядеть одинаково.

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

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

Определите команды, сигналы состояния, сигналы тревоги и точки тренда для каждого интерфейса

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

Команды и сигналы состояния не являются зеркальным отражением друг друга, хотя они часто проходят по одному и тому же физическому пути. Команда указывает устройству или зоне, что нужно сделать; сигнал состояния сообщает о том, что происходит на самом деле. Если система управления смешивает эти два понятия — например, делая вывод о том, что команда была успешно выполнена, вместо того чтобы подтвердить это с помощью независимого датчика состояния, — проект теряет возможность различать “система запросила это” и “система подтвердила, что это произошло”. Это различие имеет наибольшее значение именно в случае сбоя, когда его сложнее всего восстановить задним числом, если оно не было заложено с самого начала.

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

Вопрос о принадлежности проходит красной нитью через все четыре категории. По каждому пункту — команде, статусу, сигналу тревоги или тенденции — в рамках проекта необходимо определить, какая система его регистрирует, какая система является авторитетной в данном случае и к какой системе должен обратиться проверяющий, если когда-либо возникнут сомнения относительно зарегистрированного значения. Определение этого на уровне интерфейса, до окончательного утверждения схемы управления, позволяет избежать ситуации, когда один и тот же сигнал, по-видимому, поступает из двух систем, при этом отсутствует согласованная информация о том, какая из них является определяющей.

Назначить права владения для контроллеров блоков, шлюзов и системы управления зданием (BMS)

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

Контроллер агрегата, как правило, находится ближе всего к физическому оборудованию и обладает наиболее непосредственным представлением о его фактическом рабочем состоянии. Шлюз, если он имеется, преобразует и агрегирует информацию между контроллером агрегата и системой управления зданием (BMS), и при этом создает точку, в которой данные могут задерживаться, преобразовываться или теряться, если его роль не определена четко. Система управления зданием (BMS) расположена дальше всего от физического агрегата и, как правило, имеет наиболее широкий обзор всех зон, однако точность этого обзора зависит от качества данных, поступающих через нижестоящие уровни. Ни одна из этих трёх позиций не является автоматически “правильной” для принятия конкретного решения; выбор правильного ответственного зависит от требований данного решения — если требуется немедленное физическое реагирование, ответственность должна лежать на уровне, близком к агрегату, а если требуется межзональная координация — на уровне BMS.

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

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

Укажите поведение зоны при сбоях в связи, питании и работе оборудования

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

В группах FFU повторяются три типа неисправностей: потеря связи с блоком, отключение питания блока и просто недоступность блока по какой-либо другой причине. Каждая из них имеет свою собственную причину, и если рассматривать их как взаимозаменяемые, это приводит к реакции системы управления, которая может оказаться несоответствующей по крайней мере для одной из них. Потеря связи не обязательно означает, что вентилятор перестал обеспечивать циркуляцию воздуха; отключение питания почти наверняка означает именно это; а сообщение о недоступности блока, поступившее через какой-либо другой механизм, может как соответствовать, так и не соответствовать какому-либо фактическому изменению воздушного потока. Поскольку физические последствия в этих трех случаях различаются, запрограммированная реакция зоны не должна по умолчанию заключаться в одинаковом поведении для всех трех случаев лишь потому, что с точки зрения системы управления все они являются “неисправностями”.

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

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

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

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

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

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

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

Проверка зарегистрированных значений означает проверку того, что динамика и зарегистрированные данные, доступные на стыке между системой управления FFU и системой управления зданием (BMS), соответствуют тому, что указано в графике управления — правильные точки измерения, полученные из правильного источника и сохраненные в форме, которую проверяющий сможет впоследствии изучить. Это замыкает цикл, возвращая нас к вопросу о определении ответственности, поскольку зарегистрированное значение имеет ценность только в том случае, если его авторитетный источник был заранее установлен. Проверка этих четырёх аспектов на соответствие утверждённому графику управления на данном этапе позволяет проекту в дальнейшем рассматривать поведение системы управления как установленное, а не как предполагаемое.

Часто задаваемые вопросы

Q: Что необходимо исправить до начала окончательной адресации FFU?
A: В регистре адресации для каждого устройства следует зафиксировать идентификатор физического местоположения, рабочую зону, контроллер и связь с цепью питания. Если какие-либо из этих настроек пока не являются окончательными, соответствующие адреса следует оставить временными до тех пор, пока схема размещения не будет окончательно утверждена; в противном случае последующее переназначение адресов может привести к отключению маршрутов сигнализации и протоколов приемо-сдачи от установленного устройства.

Q: Нужно ли отправлять данные по каждому контрольному пункту FFU в систему управления зданием (BMS)?
A: Нет. Выберите команды, сигналы состояния, сигналы тревоги и значения трендов, необходимые для плана эксплуатации и мониторинга объекта, а затем зафиксируйте источник, пункт назначения и ответственное лицо для каждой выбранной точки. При наличии интерфейса с неопределённой ответственностью как команда, отвечающая за управление FFU, так и команда BMS могут полагать, что его настройкой или проверкой займётся другая сторона.

Q: Каким образом в рамках проекта следует выбирать режим работы зоны в случае сбоя связи, питания или неисправности агрегата?
A: Определите меры реагирования для каждого типа неисправности на основе оценки рисков защищаемого процесса и объекта, а также отдельно зафиксируйте ожидаемое поведение зоны в утвержденном графике управления. Используйте единый резервный вариант только в том случае, если в рамках проекта установлено, что различные неисправности приводят к одинаковым последствиям; в противном случае запланированные меры реагирования могут оставаться скрытыми до момента проведения приемочных испытаний.

Q: Какие вопросы необходимо согласовать между поставщиком средств управления и интегратором системы управления зданием до подготовки коммерческого предложения?
A: Предоставьте регистр адресации и список точек интерфейса, а затем распределите ответственность за каждую команду, сигнал состояния, сигнал тревоги и значение тренда между контроллером устройства, шлюзом и системой управления зданием (BMS). Устраните проблемы с неназначенными точками и определите требуемое поведение в случае неисправностей до того, как будут окончательно согласованы объем работ и стоимость, чтобы работы по вводу в эксплуатацию не оказались в зоне ответственности нескольких подрядчиков.

Q: Как покупателю избежать кажущегося успешного прохождения проверки, за которым скрывается ошибка интеграции средств управления?
A: Используйте утвержденную схему управления в качестве основы для приемки и проведите сквозное тестирование сопоставления физических адресов, команд зон, путей передачи сигналов тревоги и записанных значений. Записывайте ожидаемые и фактические результаты для каждой проверки; одного только отклика в режиме реального времени недостаточно, если адрес, пункт назначения или сохраненное значение не соответствуют утвержденной схеме.