Коллеги,
столкнулся с нетрадиционным подходом к диспетчеризации дымоудаления: была выполнена до выпуска ФЗ-123 и включена в автоматику вентиляции на контроллерах АСУЗ.
Хочу предложить переделать по закону, то есть на контроллерах с пожарным сертификатом, но и чтобы вывод на АРМ диспетчера АСУЗ осталась.
Почему-то производители оборудования ОПС (Болид, Рубеж), когда заходит речь про их шлюзы в MODBUS, говорят, что специализированные модули управления противопожарными клапанами не поддерживаются.
Какие есть варианты?

С2000-СП2 не поддерживаются? Вот никогда бы не подумал....

"К сожалению, пока управление "С2000-СП4" средствами "С2000-ПП" не поддерживается в полном объеме. Мы прорабатываем этот момент. Вероятнее всего, на эту тему будет выпущена новая версия "С2000-ПП"."

У Болида есть opc-сервер для ориона.

Если курс евро не пугает, то можно автоматизировать на Beckhoff или Tac - у них есть пожарные сертификаты.
На первом дешевле и проще.

хотелось бы иметь контроль цепи управления клапаном, а это оч. специфическая вещь

Добрый день.



А кто мешает завести концевики клапана через резисторы 10кОм на аналоговый вход контроллера и получить обрыв/закоротку шлейфа и открытие/закрытие клапана?
Кстати, Delta Controls тоже имеет пожарный сертификат на контроллеры, включая СКУД

"Мешает" вероятно необходимость прокладки дополнительной кабельной линии и необходимость определения работоспособности/готовности ДУ клапанов.
С другой стороны можно поставить конечные сопротивления на доп.контакты (что вы предлагаете) и гонять каждые 24 часа на открытие/закрытие - проверять работоспособность.

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

На самом деле, такая же процедура рекомендуется для водяных клапанов в режиме "зима-лето": раз в неделю прогонять их из "зимы" в "лето" и обратно для предотвразщения закисания и последующего ремонта. Всегда можно выбрать промежуток в технологии в 5-10 минут для этого действия.

Вот, вроде бы "Спрут-2" не отказывается от своего MODBUS-маршрутизатора (Плазма-Т), правда, с ним не работали
Есть еще Итриум с LONworks - но LON в нашей SCADA нет...
Может, кто еще что подскажет?

Ежеквартальное ТО никто не отменял...

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

Я от них и отталкивался, плавали - знаем, "закисают" - это мягко сказанно, я бы использовал термин "замуровываются", шток молотком выбивать приходится.
Прогонку лучше всего делать в пересменок (для непрырывного цикла работы) или после окончания рабочего дня (ночью), для вентиляции 10-15 минут некритично, только надо тормозить вентилятор на время прокрутки.

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

Я не совсем понимаю какую цель вы преследуете.
Если душевное спокойствие (вполне веская причина, без шуток) - это одно, если у вас есть реальная необходимость в таком оперативном устранении (при аварии цепи управления - сразу персонал побежит исправлять), то поведайте почему это так важно, реально интересно.


Если честно не делал специального отображения визуализации "регламентных режимов", только логи дата/результат (да/нет), экономил каналы СКАДы...

Так это просто делается: в контроллере создается переменная в которую заносится значение, соответствующее режиму работы: "Автомат", "Ручной", "Стоп", "Сервис" и т.д. SCADA отображает данный шкаф разным цветом в зависимости от режима.

Хотел услышать несколько иной ответ;
не как выполнить задачу на контроллерах АСУЗ (тоже вариант, не отказываюсь),
а как интегрировать в АСУЗ системы ОПС.
Ведь могут быть и другие задачи? Многие машут флагом интеграции, а на деле не очень.

Эм... ответ на вопрос - как интегрировать "что-то" в "нечто" ?
Ответ : использовать штатные протоколы внешней связи одной и другой системы либо делать некий "шлюз" для стыковки систем...

Более конкретный ответ вам дадут при более конкретном описании систем и используемых схем связи.

Пример интегрированной АСУ здания:
- ОВК - BACnet IP, BACnet MS/TP - Delta Controls, Sauter, Kiebak, Honeywell, JCI, Siemens, Alerton, ALC.....
- СКУД - BAcnet IP - Delta Controls;
- энергетика - BAcnet IP, BAcnet MS/TP - Delta Controls, Sauter, Kiebak, Honeywell, JCI, Siemens, Alerton, ALC.....
- пожарная сигнализация - BAcnet IP, BAcnet MS/TP - Notiefire, Esser by Honeywell, Shrack Seconet;
- ОПС - MODBUS RTU - Сигнал 2000, Edwards, Ademco? - шлюз MODBUS / BAcnet - Delta Controls, Sauter, Kiebak, Honeywell, JCI, Siemens, Alerton, ALC.....
- дымоудаление, подпор - BACnet IP, BACnet MS/TP - Delta Controls, Beckhof?, Schnieder TAC 913 -> LON
- видеонаблюдение - перехват потока MP4/ H.264 в web-портал (например enteliWEB), тревоги - либо "сухие контакты" либо поддержка протокола BACnet/MODBUS/LON со стороны CCTV;
- АРМ оператора - любая современная SCADA с поддержкой BACnet: InTouch, Iconics, Fix32, Zenon, TraceMode, ORCAview, enetliWEB, Desigo InSight.

BACnet - не совсем корректный пример, ибо он и создавался изначально для полной интеграции всех систем здания.
Типа рекомендации "забивайте гвозди молотком, а не микроскопом", а если нет молотка ?
Кстати, у BACnet есть один "косячок" касательно учёта энергии - у эл.счётков и теплосчётчиков, в подавляющем большинстве Модбас ( + и LON , ес-но), потому приходиться мудрить (заводить АСКУЭ в СКАДу отдельно или делать шлюзы), либо заказывать опционально с выходом BACnet.

тот же вопрос маршрутизации: как мысли перевести на понятный всем язык?

Конкретный вопрос: есть ли оборудование ОПС (что-то) со стандартными протоколами АСУЗ (нечто)?
Применение специализированного оборудования всегда выгодней универсального.
ОРС- сервер предполагает взаимодействие систем на уровне СКАДА (АРМ), что не всегда правильно

Ну вы хоть напишите что у вас за АСУЗ, какие протоколы юзает, АРМ на чём реализован...

BACnet в здании это не микроскоп, а эргономичный молоток, позволяющий забивать быстро и правильно любые гвозди, а иногда и шурупы с саморезами

Это косячок на BACnet'а, а производителей, которые вставляют в свои поделки протоколы "типа MODBUS" или модбасоподобный протокол.
Есть сертифицированные счетчики с M-bus, который и был разработан специально для счетчиков. Можно взять ВСх, ВСг и подключить их к импульсному входу контроллера. Из отечественных производителей ОПС только Болид сделал шлюз в MODBUS RTU, который рботает - проверяли со своими контроллерами.

А я и пишу что это "молоток".


Я конкретно про коммерческий учёт - тепло, электричество, газ.
Если вы мне найдёте на российском рынке СТАНДАРТНО укомплектованные BACnet-ом счётчики (корректоры) б/м известных фирм (так-то есть на BACnet счётчики в природе, но редко), то признаю ,что это косяк производителей счётчиков.
Но чё-та у меня сомнения по успешности сего поиска...
Счётчики кроме всего прочего собирают инфу по параметрам энергоснабжения, которые полюбому нужны оператору на АРМ, потому малость подбешивает, что нельзя спокойно "зацепиться" на эти параметры.

+ это косяк именно BACnet'а, ибо надо было уже давно сертифицировать метод коммерческого учёта (информационную систему) на базе BACnet устройств и производителей заагитировать.

К сожалению, сертифицированных для России я не нашел: есть Veris - анализатор качества с BACnet MS/TP картой и есть ONICON System-10 теплосчетчик с BACnet MS/TP.
Дело в том, что внедрение MODBUS для производителя и интегратора соотносится примерно как 30/70, а внедрение BACnet - 70/30, поэтому наши производители не будут тратить деньги, которых и так мало на хорошую имплементацию стандартных протоколов в их изделия.



BACnet International не занимается разработкой устройств или софта - он разрабатывает и улучшает протокол. Мы можем сделать систему коммерческого учета электроэнергии, воды, тепла на BAcnet как базовом протоколе, но здесь будет противоречие между требованием Энергосбыта на невозможность изменения алгоритмов и программного кода системы и принципом открытости и interoperability BACnet.

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

Очень все интересно, что выше было изложено.
Но решение от Delta Controls по контролю цепи управления (читай цепи питания исполнительного механизма) совсем не понятно.
Будьте добры его в студию, чтоб можно было в ПРОЕКТ заложить
То бишь эта схема должна предполагать действие на нею сертификата по пожарке, а не только наличие сертифицированного по пожарке оборудования используемого как угодно

Не вопрос - схема в приложении. Спаянная конструкция испытывалась с нашими контроллерами во ВНИИ ПО в Балашихе при испытаниях на соответствие тех регламенту на ППКИО

поясните!
Как это- нагрузка к выходу подключена через резистор 3 кОм?
И каков алгоритм контроля?

Выход тиристорный ~24В, далее делитель и выпрямленное напряжение поступает на вход контроллера, который сравнивает состояние выхода "Вкл/Выкл" и наличие напряжения на входе. Это контроль до пускателя дымососа. Срабатывание самого дымососа по датчику перепада давления на нем, подключенного к другому входу контроллера.

Т.е. цепь управления контролируется только при включенном выходе OP1. Бесполезная схема - если произошел пожар уже не до контроля цепей. Цепи контроля, сигнализации и управления должны контролироваться на целостность ПОСТОЯННО.
Контроль срабатывания вентилятора датчиком перепада давления из той же оперы. Ставить реле перепада на проитиводымку явный признак закисания мозгов.
К тому же не встречал реле перепада давления воздуха с пожарным сертификатом. Такие вообще есть?

Что толку с того, что вы будете контролировать цепь на целостность постоянно, а несработку дымососа не получите из-за отсутствия датчика перепада давления? Далее, наши контроллеры предназначены для ОВК, а не применения в качестве пожарной сигнализации. Заказчики попросили сделать пожарный сертификат для облегчения мониторинга как раз вентиляции дымоудаления и подпора. ВНИИ ПО проверил работу данной схемы и не предъявил замечаний. Пожарный сертификат также показывает, что наши контроллеры отвечают более жестким требоаниям к условиям эксплуатации.

Может я чего не понимаю в ПС? Как контролировать целостность цепи до дымососа?

Толк в том, что это регламентируется нормами. Почитайте СП 5.13130.2013 и ГОСТ Р 53325-2009.
Но нормы нормами, а есть еще здравый смысл, логика и наконец элементарная порядочность (хотя у многих эти категории перебиваются менеджерской алчностью): что толку в информации о не заработавшем из-за обрыва кабеля управления вентиляторе ДУ при пожаре? Уже все горит,, дыма полные коридоры, а служба эксплуатации только узнает о неисправности думоудаления. Сертифицировать под какие-то пожарные функции можно много всякого железа, но сделать из этого железа правильно работающую противопожарную установку может не получиться в принципе.

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



Видимо никак. Главное сертификат ВНИИ ПО имеется...
Значит бабосы за применение в ПА рубить еще можно. Ура!!!!