| последняя | В обсужденнии 0 реплик |
[20.07.2019 18:32:07] | | Уважаемые коллеги!
Хочу представить вашему вниманию черновик практического руководства по составлению матрицы управления противопожарной автоматикой, или пожарной матрицы. Многие наверняка уже делали на практике такие таблицы, кто-то наверняка захочет что-то добавить.
И так, пожалуйста:
По этой ссылке текст руководства
DOCX https://yadi.sk/i/UcDgF0evV_DSSg
PDF https://yadi.sk/i/pL6LroaIFQmstQ
А здесь один из первых примеров (недоделан)
XLSX https://yadi.sk/i/B8yKwOFO4ePvbQ
PDF https://yadi.sk/i/88mqemIt4e3nPg
Конструктивные критические замечания только приветствуются.
Бурчание без конструктива игнорируется.
P.S. До кучи, один из источников, который я использовал VDI 6010 часть 1 (перевод мой, местами некорректный, особенно касательно active prinzipe test) https://yadi.sk/i/NVMVXH6ElxYpGg
P.P.S. Делается факультативно для себя, чтобы упрощать работу со смежниками, коллегами, заказчиками и подрядчиками. Публикуется как “public domain, no warranty”
|
 | |
|
[22.07.2019 14:55:45] | | На практике столкнулся с трудностью. Не пойму как отразить подобные вещи:
- механическая ПДВ, по параметрам электроснабжения, рассчитана на работу в одном пожарном отсеке;
- механическое ПДВ, по параметрам ОВ, рассчитана на работу на одном этаже;
- естественное ДУ рассчитано на одну зону (<3000кв.м).
Подобную задачу вы приводите в 6.1.1 с примером о порядке эвакуации.
По моему убеждению (практике), люди не читают примечания, выноски и пр. |
| |
|
[22.07.2019 16:06:20] | | Уважаемый x-plintus, немного не понял поставленную Вами задачу. Согласен, что примечания и сноски - это плохо. Но как ни крути, сову на глобус натягивать больно (для совы точно). Матрица управления, к сожалению, не является серебряной пулей.
И так, к Вашему вопросу:
>>- механическая ПДВ, по параметрам электроснабжения, рассчитана на работу в одном пожарном отсеке;<<
Что здесь Вас смутило? То, что при получении нескольких сигналов будет превышено общее энергопотребление и выбьет защиту в ГРЩ на ППУ? Ну уж извините, такое проблемно предусмотреть. Хотя, есть надежда, что мои увещевания и увещевания ФПБ оказали воздействие на разработчиков и будет допускаться пуск ПДВ только по первому поступившему сигналу, т.е. проблема с потреблением будет снята автоматом (нормативное ограничение).
>>- механическое ПДВ, по параметрам ОВ, рассчитана на работу на одном этаже;<<
Абсолютно нормальная ситуация, что Вас смутило
>>- естественное ДУ рассчитано на одну зону (<3000кв.м).<<
Нормативное требование СП 7.13130. Ничего не поделать. Но тут есть подковырка: открытие клапанов (фрамуг) естественного ДУ приносит мало рисков, а вот включение механического ДУ, к примеру, в разных концах коридора, который поделен на несколько участков, может привести к дальнейшему распространению пожара.
А так часто наш брат наладчик программирует приборы, когда дымоудаление включается сразу на этаже. И если это для многоквартирного дома нормально, то далеко не во всяком офисном здании, гостинице, а тем более в торговом центре с атриумом это будет корректно. И именно для таких вещей вообще нужна вот эта самая матрица. Пусть проектировщик ДУ обведет на плане зону, которая защищается ПДВ и решит, из каких помещений она должна запускаться, отметив крестиками в таблице. Это его задача, пусть не увиливает. Пункт 7.20 СП 7.13130 уж очень не хотят эти негодяи выполнять, перекладывая на других.
|
| |
|
[22.07.2019 16:33:07] | | >Пусть проектировщик ДУ обведет на плане зону, которая защищается ПДВ и решит, из каких помещений она должна запускаться, отметив крестиками в таблице. Это его задача, пусть не увиливает.
Это задача проектировщика автоматизации дымоудаления. Аналогично - автоматизации пожаротушения.
Матрица - это для случая, когда никаких инженеров не нужно, монтажники сами справятся. |
| |
|
[22.07.2019 16:55:37] | | >>Это задача проектировщика автоматизации дымоудаления. Аналогично - автоматизации пожаротушения.<<
Задачу по автоматизации определяет в первую очередь технолог процесса, под технологическую задачу подстраивается вся автоматика, а не наоборот. Хвост не должен вилять собакой. С таким же успехом можно предложить возложить автоматизацию нефтеперерабатывающего завода на "автоматчиков". Кукишь Вам - автоматизация определяется химиком-технологом, а уж потом дядьки с контроллерами, со средствами измерения и т.п.
Уважаемый Georg, фраза
>>Бурчание без конструктива игнорируется.<<
была в том числе и для Вас. Или что-то дельное предлагайте, или обходите стороной эту тему. |
| |
|
[22.07.2019 17:05:43] | | Вопрос снят.
Увидел в Вашем примере блокировку ПДВ на соседних этажах. |
| |
|
[22.07.2019 17:06:24] | | Задача "отмечания крестиками в таблице", т.е. оформления документов по которым будет связана пожарная сигнализация с дымоудалением - задача автоматизации, а не технологии дымоудаления.
Таблицами никто не пользуется, оформляются паспорта каналов. |
| |
|
[22.07.2019 17:35:01] | | >>Задача "отмечания крестиками в таблице", т.е. оформления документов по которым будет связана пожарная сигнализация с дымоудалением - задача автоматизации, а не технологии дымоудаления.<<
Может в Вашем самодостаточном мирке этого и не надо. А вот американские, британские и немецкие товарищи не согласятся. Какая разница, делает ли это технолог или некий мифический "автоматчик ПДВ". Пусть у Вас это будет "автоматчик ПДВ". По сути дела какие-то предложения есть? |
| |
|
[22.07.2019 17:39:23] | | Ну понаставит технолог знаков в таблице - делать кто проект по автоматизации будет? |
| |
|
[22.07.2019 18:11:13] | | >>Ну понаставит технолог знаков в таблице - делать кто проект по автоматизации будет?<<
Этот вопрос слабо данной темы касается. Сейчас автоматизацию как ПДВ, так и СОУЭ делает неизвестно кто и как. По сводам правил автоматизация кое как через пень колоду нормируется только для АПТ.
Но вскоре все поменяется, из свода правил на АПТ выпилят почти всю автоматизацию и она окажется в своде правил вместе с СПС. И вот эти дядьки, которые проектировали СПС, будут еще и автоматику окучивать. Собственно говоря, так и сейчас дела и обстоят. И как эти технологи с автоматчиками между собой будут договариваться - вопрос открытый. Собственно, вся эта затея с матрицей - это один из вариантов, как его прикрыть. |
| |
|
[22.07.2019 18:15:08] | | Практический вопрос. Сегодня опять приходила сметчица, жаловалось - вокруг куча инженеров, а количество каналов считает она.
Как по этой таблице определить количество каналов? |
| |
|
[22.07.2019 19:14:37] | | >>Как по этой таблице определить количество каналов?<<
Каналов измерения для АСУ ТП? Никак! А вот для ПАЗ - самый самолёт. Ну или количество выходов/входов для обмена сигналами между ППКП/ППУ тоже подойдёт. Не натягивайте сову на глобус - сове больно. |
| |
|
[22.07.2019 19:28:03] | | Ну так как определить по таблице количество каналов? |
| |
|
[22.07.2019 20:24:30] | | >>Ну так как определить по таблице количество каналов?<<
"Как перевезти на жигулях 2101 пять тонн кирпичей за один заход?"
Каких каналов? Для чего? Если это ПАЗ, то IEC 62881 смотрите, может чем-то поможет. Здесь не АСУ ТП обсуждается. |
| |
|
[22.07.2019 20:59:15] | | А если по этой таблице каналы нельзя даже посчитать, как их можно проектировать? |
| |
|
[22.07.2019 21:25:10] | | ***Ну так как определить по таблице количество каналов?
Можно подумать что кто-то, когда-то их точно определял? Всегда пишут приблизительно, и подгоняют смету под необходимую сумму. |
| |
|
[22.07.2019 21:35:59] | | >Всегда пишут приблизительно, и подгоняют смету под необходимую сумму.
А потом сметчица заказчика приходит ко мне, я говорю сколько каналов и она режет сумму. |
| |
|
[22.07.2019 21:38:28] | | >>А если по этой таблице каналы нельзя даже посчитать, как их можно проектировать?<<
Сова и глобус.
Напоминаю:
>>Бурчание без конструктива игнорируется<< |
| |
|
[22.07.2019 23:18:23] | | Не знаю как к этому относятся другие, но по мне как вообще можно проектировать системы ПБ без разработки и последующей реализации проектных решений, отраженных в рассматриваемой тут "матрице".
Вот к примеру, пришел один специалист по пуско-наладке и что-то там наконфигурировал. А с чего он так решил, на основании чего он принял такие решения. Через год-два на объект приходят ребята из ТО. Не понимая, что тут было изначально задумано, они это как-то переделывают на свой лад, подчас отключая те или иные связи. Чем ниже уровень профессионализма, тем проще становится система.
А что же было изначально, в каком виде проект (рабочки по каждой систем) был когда-то согласован.
Этого уже никто никогда не узнает. Что в итоге получим - никак не связанные системы. Т.е. ПДВ, СОУЭ и т.п будут сами по себе и никак не связаны с первичной информацией от СПС. Это равносильно отсутствию этих систем.
Это то, что мы сейчас имеем в большинстве случаев, полагаясь на "мастерство" дежурных по пожарному посту в режиме дистанционного управления. Это глупейшая и грубейшая ошибка. Попробуйте посадить меня на незнакомый объект, и не зная схем по той же ПДВ, я даже под дулом пистолета ничего не буду нажимать и включать.
Поэтому на объекте должна быть проектная документация (тут у меня всегда возникает вопрос, а в каком объеме должна или не должна быть рабочка, а как быть с исполнительной). И безусловно в этой документации должна быть на первом месте "матрица". Если ее не будет, то система противопожарной защиты никогда не будет работоспособной. И для всех смежников по СПС это должна быть основная задача - быть согласованным с нею.
Но с матрицами тоже не все так просто.
С простыми алгоритмами еще как-то многие и могут справиться. И вдруг у какой-то реальной ситуации может быть три решения, в зависимости от дополнительных условий. Вот тут ступор. В этом случае к матрице должны быть какие-то дополнения/пояснения. И это может быть описано в виде стандартного графического описания алгоритмов. И тогда около какого-то крестика на пересечении входов и выходов ставим соответствующий номер ссылки, по которой можно будет найти этот алгоритм.
Почему многие специалисты против этих матриц в рабочке. Так это самая сложная часть документации, тут надо думать и понимать всё, что будет происходить на объекте. А кому нужна дополнительная ответственность за принятые решения. Вот и канают под дурочку - а у меня этого не было предусмотрено договором, моя задача только СПС. Вот кому бы я надавал по рукам, таких надо выгонять с этого рынка, не можешь ср..ть, не мучай ж..пу.
При обсуждении проекта нового СП на СПС для меня это был одним из самых главных вопросов. Что там в итоге от этого будет, надеюсь уже скоро увидим.
|
| |
|
[22.07.2019 23:32:47] | | Кстати, я совсем забыл, что в начале предыдущего поста надо было с начала сослаться на моё более развернутое обоснование необходимости "матрицы" - https://avtoritet.net/library/press/..., а уже потом писать весь этот пост. Но как всегда - хорошая мысль приходит опосля. Вроде бы мне уже и не 16 лет, но почему-то эмоции, если их не удерживать мощными цепями, все равно почему-то всегда преобладают над логикой. |
| |
|
[24.07.2019 10:02:00] | | >>Почему многие специалисты против этих матриц в рабочке. Так это самая сложная часть документации, тут надо думать и понимать всё, что будет происходить на объекте. А кому нужна дополнительная ответственность за принятые решения. Вот и канают под дурочку - а у меня этого не было предусмотрено договором, моя задача только СПС<<
Уважаемый ФПБ, Вы зацепили очень важную тему. Действительно, сейчас нафиг эта матрица никому не нужна, ибо процентов 70 проектов делаются, что называется, по-рыхлому. Сначала один за малую толику рисует ровно столько, чтобы эксперт не доставал, потом другой использует этот "качественный" материал, чтобы сделать рабочку, по которой можно составить смету и провести монтаж. Про пуско-наладочные работы и думать не принято. Один Georg со своей сметчицей какие-то каналы считают, делать им больше нечего ;-). А потом, ближе к концу стройки находят "шаристого" слаботчника со словами: ты тут половину смонтировал, бери ноутбук в офисной бытовке и налаживай. Если система импортная, то может еще учится направят. Я эту кухню знаю не понаслышке.
И как это юное дарование справится с задачей, будет ли опытный наставник - это как повезёт. Кто-то учится, а кто-то начитавшись "вредных советов" скрещивает ужа с ежом по Contact ID. Никаких документов этому наладчику не дают, да даже тот кто делал рабочку чаще всего имеет ооочень смутное представление, как это потом все работать должно.
И тут скоро подстава будет в СП на автоматику. Там какие-то зоны пожарной сигнализации, противопожарной защиты, и первая почему-то должна быть меньше второй. Да что это за зоны, нафига они нужны - только эти вопросы будут всплывать здесь на форуме ближайшие лет пять. Куда там до матрицы?
Кстати, матрица управления, по моему мнению, хоть и центральный элемент, но далеко не самодостаточный. Нужна к этой матрице еще и схема зонирования, тоже выполненная по каким-то определённым правилам, чтобы на ней была не муть, а тот что действительно нужно. И по этой теме я тоже малыми шажочками готовлю практическое руководство. Хотя в этом нет никаких ноу-хау, кто действительно пытался решить грамотно своим пешком проблематику с описанием алгоритма, доходил до тех же решений: матрица и схема зонирования. Встречается еще часто, как я его называю, "подход сценариев", когда выделяются определённые сценарии работы в таблично-тестовом виде. Тоже неплохо в целом, но слишком объёмно, читать и воспринимать сложно, а внесение изменений превращается в настоящий ад. |
| |
|
[24.07.2019 11:58:27] | | adgernaut ® [24.07.2019 10:02:00] "...Действительно, сейчас нафиг эта матрица никому не нужна, ибо процентов 70 проектов делаются, что называется, по-рыхлому..."
В свое время в ТЗ прописывал требования по матрице, но проектировщики только хлопали глазами не понимая зачем нужен подобный алгоритм. Людей имеющих образование по профилю или "болеющих" и думающих по пальцам пересчитать. Решил, что заниматься обучением и убеждением дело пустое и пошел немного по другому пути в части ДУ - через п. 7.18 и 7.20 СП7 надавил на ОВ чтобы выдавали нормальное ЧТЗ с алгоритмом. |
| |
|
[24.07.2019 20:24:22] | | madoff ® [24.07.2019 11:58:27
>>Решил, что заниматься обучением и убеждением дело пустое<<
Ну вот те каракули, которые я начеркал, как раз для этого, чтобы каждый раз все сызнова не объяснять. Пока это только начало.
>>и пошел немного по другому пути в части ДУ - через п. 7.18 и 7.20 СП7 надавил на ОВ чтобы выдавали нормальное ЧТЗ с алгоритмом.<<
Ну хоть у кого-то получилось выжать из ветродуев нужную информацию. Сколько я не пытался, ничего вразумительного. Посчитать по методичке - так это всегда пожалуйста, а как спросишь, как же в итоге оно должно работать - то круглые глаза. А если чуть поглубже копнешь, то сразу понимаешь, что бездна и полное непонимание вообще зачем это делается.
Кстати, если уж у Вас получилось стребовать с ОВшников ТЗ с алгоритмом, то можете поделиться примерами, как оно сделано. В конфедециальном порядке на почту adgernaut@yandex.ru , если не затруднит. |
| |
|
[24.07.2019 21:15:51] | | Попробую найти, но не гарантирую. Сменил место работы и ступень, и сейчас не до ЧТЗ. Даже не знаю осталось ли чего на компе.
P.S. Вам в любом случае удачи, дело нужное и полезное. Глядишь и назовут эту матрицу "таблицей Адгернота"))) |
| |
|
[24.07.2019 21:35:26] | | Лично мне такая таблица кажется излишне сложной. Мне больше нравится "подход сценариев", когда выделяются определённые сценарии работы в таблично-текстовом виде. У нас не так много типов систем пожарной автоматики, (СОУЭ, АПТ газовое, АПТ водяное/пенное, Дымоудаление/управление вентиляцией) Для каждого из них можно написать шаблонный сценарий, который надо будет только привязать к ЗКПС и исполнительным устройствам. В итоге, описание алгоритма автоматики получится в текстовом виде, который кажется более понятным человеку, не связанному с пожаркой. Понятность нужна не только для того, что бы пусконаладку могли делать люди с образованием ниже среднего, но и для того, что бы собственник объекта (представитель собственника) мог сам проверить работу системы. У нас сейчас за все отвечает собственник, но проверить правильно ли работает его система он не может. Опасаюсь, что таблица будет ему не понятна. Проще текстовое описание: что, как, в какой последовательности, от чего должно включаться и выключаться. Список установленных систем собственник имеет, он за их создание деньги платил, должен на баланс принять. А как они должны работать он не знает. |
| |
|
[25.07.2019 1:06:57] | | Уважаемый Alex116, серебряной пули точно нет в этом вопросе. Разумеется, лучше использовать накатанный вариант. Тут уж от мастерства все зависит: кто-то может очень здорово разбить автоматику объекта на сценарии, а кто-то и матрицу испоганить, что без пол-литра никак не разобраться.
Теперь расскажу, за что же я невзлюбил "сценарии". Причин тому несколько.
1. Такой подход имеет малую универсальность. От объекта к объекту приходится выискивать те самые минимальные сущности, от которых мы уже эти сценарии расписываем. Очень часто в качестве такой сущности выступает некая зона ДУ, реже ПТ. И эти сущности, которые лежат в основе сценариев имеют разную природу в зависимости от системы, от которой пляшем. СПС здесь в целом на вторых ролях.
2. Сценарии в виде текста не способны дать представление о географии на объекте, т.е. способны, но не всегда с требуемой однозначностью. Графикой их тоже приходится дополнять.
3. Если за основу для сценария берётся какая-то зона СПЗ, то более крупные зоны СПЗ будут повторятся в нескольких сценариях. Можно делать многоуровневую таблицу, но "чем дальше в лес, тем толще партизаны". Все сложнее работать с документом. Если же и исполнительные устройства вносить в списки, то это опять же дублирование ненужной информации в виде списка клапанов. И не дай бог у какого-то из них изменится проектное обозначение - или лопатить весь список, мало ли где описка была.
4. Внести изменения в виде выделения дополнительного сценария - приходится анализировать все заново, выяснять, какие же сущности проектировщик в начале брал за основу.
5. Стопки бумаг со сценариями сложно окинуть взглядом и выявить какие-то закономерности, т.е. сложно анализировать.
А теперь то же самое о матрице
1. Матричное представление довольно универсально, минимальные сущности выискивать не надо, они сами напрашиваются, если что-то должно создавать разный набор значков в пересечениях, то вот эта сущность. Можно не заморачиваться с объединением их под общий знаменатель, если хочется выделить, то просто оставляем отдельную строку. Это также и к 4 пункту относиться.
2. Также как и сценарии, матрица не даёт географического представления, но изначально предполагается, что можно разделить зонирование СПС (или спринклерного ПТ) и прочей автоматики, т.е. поиск минимальной сущности упрощается. Ссылками на графику дополнять удобнее.
3. Повторяются в матрице только значки в пересечениях, что проще и сложнее ошибиться при корректировке. Минимальная вложенность и плоская структура для большинства вариантов алгоритмов,
4. Простое внесение изменений: удаляем/добавляем строки и столбцы, меняем значения в пересечениях. Поиск сущностей завязан на географию by design, т.е. работать надо с понятным любому человеку планом здания, а не системными единицами, в которых разбираются только узкопрофильные специалисты.
5. Матрицу можно запихнуть в один лист, т.е. взглядом проще это богатство окинуть и найти закономерности.
В целом же матрица как раз отражает сценарии, только немного в другом виде. Каждая строка - это и есть отдельный сценарий. Просто вот в таком табличном виде.
Но как я писал выше, изгавнякать можно любую идею. Именно поэтому я выделил проектную матрицу как особый вид, который оперирует в основном географическими понятиями зон. Причинно-следственные связи в таком случае понятны любому. К примеру: если в Москве меньше 5 градусов, то включить отопление в Хамовниках, Копотне, Бирюлево и т.д. Нужно только карту приложить не забыть. Карта - схема зонирования. Именно по этой причине проектная матрица должна существовать на всем протяжении жизненного цикла, чтобы и собственнику, и инспектору на пальцах все можно было объяснить, без глубокой терминологии.
В том же примере, что по ссылке - это уже "полная матрица" с исполнительными устройствами. Она уже требует квалификации, но и матрица в таком виде тоже нужна. Без этого не осуществить полноценно пуско-наладку и комплексное тестировние. С полной матрицей еще есть небольшой лайфхак - если сделать на АРМ план с этой таблицей и привязать нужные ЗКПС и исполнительные устройства, то при плановом тестировнии проще некуда становиться все проверять. Главное, чтобы от исполнительных устройств была обратная связь. |
| |
|
[25.07.2019 1:16:25] | | >>P.S. Вам в любом случае удачи, дело нужное и полезное. Глядишь и назовут эту матрицу "таблицей Адгернота")))<<
Мне, конечно, лестно. Но это точно не мое ноу-хау. Такая табличка требуется многими нормативными документами. Кое что Вы можете увидеть в библиографии, а в первом посте я дал ссылку на перевод VDI 6010 часть 1. И видел разные вариации матрицы в нескольких десятках чужих проектов. Я же провожу работу по унификации подхода работы с этой таблицей. |
| |
|
[25.07.2019 14:46:28] | | Посмотрел таблицу. Мне лично нравится.
Однако как быть с системой оповещения 5-го типа, где необходимо реализовать оповещатели с изменяющимся смысловым значением? |
| |
|
[25.07.2019 17:52:52] | | Интересно. Но если вы хотите, чтобы ее понял любой проектировщик/монтажник, то надо вводить более строгое определение атрибутов (наподобие УГО) с расшифровкой всех используемых сокращений. Например, тот же пожарный отсек в вашем примере можно назвать и "ПО-1" и "1-ПО", а такого быть не должно, должен быть только один вариант. |
| |
|
[25.07.2019 18:35:12] | | Если использовать трёх- и четырёхбуквенные русскоязычные сокращения, то в список сокращений атрибутов действий можно и не заглядывать. А для для заинтересованных англоязычных заказчиков выполнять матрицы по существующим европейским нормам. И убрать из таблицы номера листов схем зонирования - прикладывать их к матрице. Графы "структурная схема (номер листа)" и "изменение" использовать для себя на этапе проектирования, в готовую матрицу не включать. Так ли необходима в примере матрицы нумерация 1-36 и А-BZ? В общем я за минимализм и читаемость матриц, всё написанное моё субъективное видение. Матрица заинтересовала, даже заглянул в серию ГОСТов Р МЭК 61508. |
| |
|
[25.07.2019 19:37:43] | | Tomches ® [25.07.2019 14:46:28]
>>Однако как быть с системой оповещения 5-го типа, где необходимо реализовать оповещатели с изменяющимся смысловым значением?<<
С системой оповещения 5-го типа такого типа матрицей, мне кажется, никак не разобраться. Уже на 4-м можно славно споткнуться. Тоже с этими вопросами хочется для себя разобраться, но это не скоро будет :-(
zsa ® [25.07.2019 17:52:52]
>>Но если вы хотите, чтобы ее понял любой проектировщик/монтажник, то надо вводить более строгое определение атрибутов (наподобие УГО) с расшифровкой всех используемых сокращений.<<
К сожалению не всегда можно определять значения атрибутов при разработке матрицы. Вот с названиями тех же пожарных отсеков и/или секций - то они часто определяются на этапе архитектурного проектирования и уже даются в готовом виде. Никто ради пожарной автоматики не будет вносить изменения во все другие разделы, где уже использовано название из АР. А как известно, пожарная автоматика идет вообще последняя в очереди, т.е. когда есть АР, ОВиК, ЭОМ, ПДВ, АПТ и т.д. Но мне в целом нравится такая идея обеспечить единообразие. Попробую изобразить что-то в приложении. Ну и все же матрица не для монтажника, а для инженера-наладчика, инженера по ТО, инспектора и прочих ответственных лиц.
j_flack ® [25.07.2019 18:35:12]
>>Если использовать трёх- и четырёхбуквенные русскоязычные сокращения, то в список сокращений атрибутов действий можно и не заглядывать.<<
В этом действительно что-то есть. Но тогда ячейки в пересечении будут прямоугольные. На маленькой матрице ничего страшного, а на большой уже нерационально. Если хочется обойтись без таких сокращений, то можно в атрибуте исполнительного устройства прописать действие. Например у клапана написать "Открыть", у оповещения "Предупреждение" и т.п.
>>А для для заинтересованных англоязычных заказчиков выполнять матрицы по существующим европейским нормам.<<
Да у них еще нет этих норм, так, в общем виде. Это просто у меня в примере англоязычные сокращения, но можно и на кириллицу перевести с помощью "найти-заменить", дело пяти минут. Мне кажется, что лучше в этом аспекте не стоит ограничивать, только мягкие рекомендации можно еще добавить.
>>Графы "структурная схема (номер листа)" и "изменение" использовать для себя на этапе проектирования, в готовую матрицу не включать.<<
Атрибут "структурная схема" я посчитал необязательным, т.е. его можно вообще не использовать в принципе. По таким же соображениям как и у Вас. Все только по взаимной любви.
А вот атрибут "изменение" очень важный, причем не на этапе проектирования, а уже позже - при пусконаладочных работах, вводе в эксплуатацию и при самой эксплуатации. Версии отслеживать проблематично и очень важно понимать, когда было конкретно что-то затронуто. Можно сказать, что это на горьком опыте проверил. Ну и IEC 62881 того же мнения. Видимо не просто так.
>>Так ли необходима в примере матрицы нумерация 1-36 и А-BZ?<<
А как сослаться на какую-то часть таблицы без этой нумерации? Это как в архитектурных чертежах есть оси, на шахматной доске и т.д. А если матрица большая, то без нумерации и периодического повторения их в таблице очень легко запутаться. Лично я считаю нумерацию необходимой. Может у Вас получится меня переубедить :-)
>>В общем я за минимализм и читаемость матриц<<
Категорически поддерживаю! Но сложно соблюсти баланс между читаемостью и необходимой информативностью. Тут уж только опытным путем можно что-то выводить. Вот я и спрашиваю тут у всех, как же этот компромисс найти.
|
| |
|
[26.07.2019 6:22:49] | | dgernaut ® [25.07.2019 19:37:43]
<<С системой оповещения 5-го типа такого типа матрицей, мне кажется, никак не разобраться. Уже на 4-м можно славно споткнуться. Тоже с этими вопросами хочется для себя разобраться, но это не скоро будет :-(
Думаю СОУЭ должна быть адресной. Тогда в таблице увеличится кол-во исполнительного оборудования.
В принципе сценарии возникновения пожара уже предусмотрены в Вашей матрице (т.е. в зависимости от места обнаружения).
Следующий шаг это подробное разложение работы системы оповещения.
1. Применительно к лестничных клеткам с подпором воздуха - так как производительно вентилятора рассчитывается на две открытых двери (дверь в лк на этаже пожара и дверь выхода из лк) необходимо определить очередность оповещения по этажам.
2. Например есть объект на котором этаж состоит из блоков. В зависимости от места нахождения очага пожара необходимо перенаправлять людские потоки. Это можно предусмотреть только с помощью: световых оповещателей направления с изменяющимся смысловым значением (на практике два адресных оповещателя), записью речевых текстов в зависимости от сценария, учебными тренировками по отработке эвакуации.
А что Вас смущает в 4-м типе СОУЭ?
|
| |
|
[26.07.2019 9:54:46] | | Уважаемые Tomches, немного поясню, почему системы оповещения 5-го и часто 4-го типа сюда не влезают.
По 5-му типу. Если рассматривать в общем случае, не применяя к конкретному объекту, то есть такие особенности:
1. Развитие во времени;
2. Изменение сценария в зависимости от новых поступающих сигналов.
В связи только с изменяемостью мы можем получить n! возможных вариантов развития событий, где n - количество независимых путей (направлений стрелок). Если взять количество зависящих от времени состояний, то количество возможных вариантов увеличивается до (k*n)! Т.е. в общем виде алгоритм можно изложить, наверное, только используя теорию автоматов, матрицы переходов и состояний конечного автомата. Очевидно, что это не для людей. А если учесть, что еще надо это как-то скрестить с людскими потоками, то можно сделать вывод, что без профессионального математика в команде проектирования никак не обойтись. Именно поэтому 5-й тип я считаю исключительно мифической мертворожденной идей обчитавшихся книжек про фантастику людей. Либо он имеет право на жизнь, но должен быть существенно упрощен по сравнению с существующими общими формулировками.
По 4-му типу немного проще. В моем примере таблицы приведен вариант статической СОУЭ 4-го типа. Но уже не редкость системы оповещения с фазовой эвакуацией. Для этого даже есть некая теоритическая база, можно найти статьи как на русском, так и на зарубежных языках, есть руководства (на английском, немецком). И тут уже с фазовой эвакуацией начинается заминка, т.к. зависит от времени. К сожалению, в одну ячейку мы не можем вписать множество состояний. Таким образом в матрице мы можем отметить только начальное состояние, указав, что вот этот сценарий у нас сейчас запускается. А сам сценарий придётся приводить отдельно, не в матрице, в координатах зоны СОУЭ и времени. И для фазовой эвакуации непонятно как быть с поступлением второго сигнала, игнорировать его, сочетать два сценария от разных зон или дла второй и последующей зоны просто запускать эвакуацию в них, не меняя принципиально первоначальный сценарий. Тут уж только числовым моделированием конкретного объекта можно что-то решить. |
| |
|
[26.07.2019 13:29:52] | | Давайте теперь разберемся какие изменения могут происходить при развитии пожара. |
| |
|
[26.07.2019 16:51:51] | | >>Давайте теперь разберемся какие изменения могут происходить при развитии пожара.<<
Может происходить что угодно для СОУЭ пятого типа с точки зрения автоматизации. В любом случае сейчас пока об этом глубоко обдумывать некогда. Но если у Вас есть какое-то предложение, то внимательно слушаю. |
| |
|
[27.07.2019 23:29:59] | | Еще в 2011 году по части зонирования и управлению СОУЭ 4-5 типа был очень интересный материал. Почему-то я всё забываю его разместить у себя на авторитете в библиотеке. Так и сейчас с трудом его у себя нашел. Надо вообще-то объявить субботник по прочистке моих архивов. Я когда вижу что-то интересное, даю как бы временные имена/названия, в надежде, что вот вот я к ним вернусь. А потом уже через день-два забываю. И так было с этим материалом. Файлу дал такое название, что еще год можно было искать.
Еще тогда, в те года были даны очень конкретные решения по расчету и проектированию этих систем с точки зрения зональности как СПС, так и СОУЭ. Вот адрес - https://aercom.by/wp-content/uploads...
И опять-таки всё начинается с ЗКПС. Так что от этого термина, и от этой единицы "измерения" все равно никуда не деться. Так и требования к матрице уже по этой части начинают расширяться. |
| |
|
[28.07.2019 9:54:50] | | В статье Мисюкевича говорится о том, что ложное срабатывание СОУЭ и эвакукция - чрезвычайная ситуация и должно регулироваться законодательством о чрезвычайных ситуациях.
Будет на сайте ГУ МЧС писаться: в регионе за прошедшие сутки чрезвычайных ситуаций объектового хараткера - 35; муниципального - 27; регионального - 11; федерального - 1. Тогда ложные срабатывания прекратятся без всяких матриц. |
| |
|
[28.07.2019 12:26:09] | | Все же уникальный персонаж, этот наш Georg. Кто про что, а вшивый про баню. |
| |
|
[28.07.2019 16:13:31] | | ***В статье Мисюкевича говорится о том, что ложное срабатывание СОУЭ и эвакукция - чрезвычайная ситуация
У Н.В. Гоголя персонаж есть такой-Манилов. Писаки, хоть-бы думали о чем пишут. Если по каждому ложняку режим ЧС вводить, все только этим и будут заниматься?
***Тогда ложные срабатывания прекратятся без всяких матриц.
Ложные срабатывания, от сайтов и матриц не зависят.
|
| |
|
[28.07.2019 20:50:33] | | Уважаемый BG-34, это очень хорошо, что Вы вспомнили нашего Николая Васильевича - мастера гиперболы и гротеска. И не смотря на то, что наш уважаемый белорусский коллега тему затронул довольно серьёзную, тематика издания все же предполагает ориентацию на более широкую аудиторию, нежели научный бомонд, т.е. использование литературных приёмов вполне уместно. Уж кто бы стал читать статьи уважаемого ФПБ, если они писались в строго научном духе. Он это точно может, уж не сомневайтесь. Но живой язык, красочные образы - они иногда могут сделать больше, чем какой нибудь график, идеально вписывающийся в логнормальное распределение или три этажа формул.
И возвращаясь к 5-му типу СОУЭ, Вот была в стародавние времена статья про пятый тип. Прошло уже много лет, но воз и ныне там.
https://algoritm.org/arch/arch.php?i... |
| |
|
[28.07.2019 23:02:36] | | Идеальных статей не бывает в природе.
У каждого в голове свои тараканы.
У нас в редакции лежит очень много материалов, просто ни о чем. В смежных изданиях их очень часто даже публикуют за неимением других. Т.е. читаешь, и не можешь понять, зачем всё это было написано, когда об этом знает каждый, кто хоть раз участвовал в монтаже какой-нибудь системы.
И наоборот. Есть статьи даже не научные, а околонаучные, когда заумным языком и с формулами наперевес пишут, лишь бы что-то написать для отчета. От какой-то науки они также далеки, как и от практики.
Но есть статьи, в которых есть нормальное начало, т.е. есть о чем порассуждать. Но, к сожалению, бывают в них и не совсем корректные моменты. Нельзя из-за этих моментов ставить крест на всем материале. Не боги горшки обжигают.
Вопрос зонирования у нас вообще до сих пор находится где-то в потустороннем мире. Даже сейчас в проектах новых стандартов и сводов правил та же ЗКПС имеет разную формулировку. Где-то это часть территории или помещений, а где-то это каким-то образом сгруппированное некое количество извещателей.
Дальше больше. Появятся связанные (зависимые) зоны защиты, а еще и вложенные зоны защиты. И что-то с этим со временем тоже придется делать, а опыта-то формулировать все эти вопросы еще нет. Придется всё это собирать по крупицам, обсуждать в том числе и здесь, чтобы общими усилиями найти удобоваримые решения.
И каждая такая статья, как у того же Мисюкевича Н.С., это попытка найти точки опоры, чтобы в дальнейшем всем вместе, а может просто уже другим попытаться идти дальше в этом направлении, с учетом исключения допущенных каких-то ошибок или заблуждений добровольного характера. Но ведь он еще в 2011 году, живя в совсем другой стране, поднимал вопрос о зонировании, и, как следствии, о той же матрице. Так ведь в этой статье помимо всего прочего очень много здравого смысла, почему я и дал на нее ссылку. Но обсуждать начали совсем другое.
Но вот так, чтобы "Писаки, хоть-бы думали о чем пишут", это исключительно некорректно по отношению к этим людям, с учетом того, что практически никто за все эти статьи не получал и трех рублей, чтобы окупить хотя бы средства потраченные на электроэнергию.
И я был бы рад, если бы к нам в редакцию поступало бы побольше таких статей.
Гораздо проще на каком-нибудь форуме по ником написать пару слов или строчек, что авторы уроды и ничего не знают о реальной жизни, и ждать, что кто-то когда-нибудь разработает стандарты и всякие своды правил, которые всех устроят, и решат все стоящие проблемы. |
| |
|
[28.07.2019 23:12:07] | | ***Гораздо проще на каком-нибудь форуме по ником написать пару слов или строчек, что авторы уроды и ничего не знают о реальной жизни
Я никого не оскорблял, но если люди берутся писать, надо писать о реальных проблемах , которых выше крыши, а не разводить маниловщину.
|
| |
|
[29.07.2019 9:45:02] | | >>надо писать о реальных проблемах , которых выше крыши<<
Уважаемый BG-34, может подскажите, что это за темы такие? Я думаю, "писакам" тоже будет интересно ознакомиться хотя бы с частью этого списка. А то высасывают из пальца темы. |
| |
|
[29.07.2019 21:53:43] | | ***может подскажите, что это за темы такие?
Да легко, достаточно почитать этот форум, первое что пришло на ум:
1. Многочисленные несоответствия, разночтения в нормативных документах по ПБ.
2. Нет узаконенной методики акустического расчета оповещения.
3. Нет узаконенной методики внедрения и эксплуатации СПМ.
4. ОКЛ? и т.д. и т.п. Вопросов масса.
***Я думаю, "писакам"
Ни кого не хотел обидеть, просто мы практики воспринимаем каждое печатное слово, как истину в последней инстанции.
Хотелось-бы что и ученые люди, когда что-то пишут (независимо от того платят им, или нет, мне тоже никто не платит за писанину здесь :) ) осознавали моральную ответственность за написанное.
|
| |
|
[29.07.2019 23:02:23] | | >просто мы практики воспринимаем каждое печатное слово, как истину в последней инстанции
В помощь. Википедия:Авторитетные источники: https://ru.wikipedia.org/wiki/%D0%92...
Если источник не подходит даже для Википедии, не нужно его использовать при проектировании систем безопасности для людей. |
| |
|
[29.07.2019 23:52:18] | | В помощь. Википедия:Авторитетные источники: https://ru.wikipedia.org/wiki/%D0%92...
Я Википедию не читаю, привык верить профессионалам.
Но с возрастом, из-за некоторых начинаю терять веру :) . |
| |
|
[30.07.2019 9:28:08] | | >привык верить профессионалам
Как раз по ссылке: "Также спросите себя: А нет ли у публикатора каких-либо интересов в данной области, которые могут исказить представленную информацию?"
Интерес в данном случае легко понятен - обосновать существование (и оплату) инсталляторов, настройщиков. Причем, чтобы вместо рабочего-настройщика был инженер-инсталлятор, добавляется наукообразности. |
| |
|
[30.07.2019 10:02:36] | | Вот читаешь иногда здесь на форуме высказывания и плакать хочется. Европейская культура, частью которой, как мне казалось мы являемся - ничто. Имена великих философов: Платона, Сократа, Декарта, Ньютона, Гегеля, Канта, да и товарища Ульянова - все это пустые звуки. Научный метод - не, не слышали. Диалектика, гипотеза, теория, аксиома, эксперимент - чушь какая!
Вот Georg тут целыми днями зависает, цитирует Википедию, изучает свежие законы. Хочется спросить, а работать то приходится этому человеку? Да похоже нет, все книжечки читаем. Единственное наследие, которое он такими темпами оставит - так это груда комментариев на 0-1.ru, причём откровенно пустых, не несущих абсолютно никакой смысловой нагрузки. Ярчайший представитель того слоя общества, который в первой половине XX-го века очень метко прозвали "вшивой интеллегенцией". За напускной завесой умника скрывается... ничего там не скрывается, пустота.
А Вы, уважаемый BG-34 зря так упираете на приоритет практики. Как известно, грош цена тому эксперименту, который невозможно повторить. Как и грош цена той гипотезе или теории, которая не подтверждается практикой. Упирать только на практику - это как ходить на одной ноге. Можно, но очень неудобно. И думать надо прежде всего своей головой, несмотря на то что пишут какие-то профессионалы, и даже "авторитетные источники". Вам проще всего "в полях" многие такие аспекты проверять, было бы желание. |
| |
|
[30.07.2019 12:12:14] | | ***А Вы, уважаемый BG-34 зря так упираете на приоритет практики.
Уважаемый коллега, я совершенно на это не упираю. Без науки, практика-ничто. Я просто излагаю свое видение, не с целью кого-то задеть, а токмо ради нашего общего дела.
***Вам проще всего "в полях" многие такие аспекты проверять, было бы желание.
Да проверяем, по мере возможности. Но возможности с каждым годом все меньше и меньше. Клиенты у нас нищие, сильно не разбежишься с экспериментами. Не то, что было к примеру, лет 15-20 назад. |
| |
|
[30.07.2019 21:09:15] | | <<Зонирование объекта при совместном использовании систем пожарной сигнализации, оповещения о пожаре и управления эвакуацией
Хорошая статья. Не рассмотерены в ней системы противодымной защиты, но думаю в первом приближении и этого достаточно.
<<План эвакуации является документом, который невозможно грамотно составить вне логики управления процессом эвакуации.
На сегодняшний день большинство путей эвакуции существующих объектов не соответствуют "современным" требованиям (по ширине, количеству выходов, расстановке, и организации - лк/выход наружу).
Специалисты, которые на существующем плане рисуют план эвакуации, не обладают подобными знаниями.
<< Пространство зоны оповещения может быть разделено на несколько зон управления эвакуацией, для которых необходимы или (и) разные звуковые, речевые, световые сигналы оповещения, и (или) их время трансляции, и (или) применяемые для этого технические средства/
Касаемо световых оповещателей направления эвакуации надо сказать, для определения места их положения необходимо графически определить направления людских потоков, а также места изменения их направления и уже с учетом данных фактором установить необходимость установки стрелок с учетом видимости.
<<Зонирование объекта начинается с расчетов необходимого и расчетного времени эвакуации из помещений.
Здесь также надо добавить, что расчетное время эвакуации из того или иного помещения будет зависить от места положения очага пожара, при этом ближайший к нему выход с этажа пожара будет заблокирован. При расчете могут возникнуть ситуации когда без организации задержек в СОУЭ будут возникать скопления людей в результате чего могут возможна паника, давка и т.д.
Соответственно количество сценариев возникновения пожара должно равняться количеству эвакуационных выходов с каждого этажа.
В результате вышесказанного расчетное время эвакуации будет измененяющимся в зависимости от:
- сценария возникновения пожара;
- организации очередности включения зон оповещения в зависимости от наступления ОФП в той или иной зоне оповещения;
- вынужденной задержки оповещения в зонах (в связи: необходимостью первоочередной эвакуации зоны где ОФП наступают быстрее; возникновения скопления людей более 6 мин).
Под скоплениями в соответствии с Методикой понимаются участки, где плотность людского потока на путях эвакуации превышает значение 0,5 м2/м2.
Статичискими, т.е. неизменными в результате расчетов можно получить только необходимое время эвакуации, равное 0,8хвремени блокирования путей эвакуции ОФП.
Расчетное время эвакуации для каждого сценария придется моделировать в следующих случаях:
1. Наличие проемов в перекрытии (атриум, эскалатор, лестницы 2-го типа и т.п.).
2. Не соответствие путей эвакуации требованиям пожарной безопасности по ширине.
3. Когда необходимое время меньше расчетного времени эвакуации.
Если эта задача не решается необходимо определить расчетом необходимую ширину зауженного участка и выдать техзадание Заказчику на расширение.
<<Натурные наблюдения за процессом эвакуации в помещениях с массовым пребыванием людей (театры, кинотеатры, актовые залы) показывают, что задержка эвакуации, увеличивающая продолжительность эвакуации из помещения происходит, как правило, при движении через дверные проемы.
Следовательно, для исключения задержки движения людского потока на выходе из помещения и уменьшения общего времени эвакуации, целесообразно ограничить скорость движения к эвакуационным выходам, обеспечив пропускную способность дверных проемов с интенсивностью ниже максимальной.
Здесь автор подменяет понятие "скопление" понятием "задержка". Иногда действительно имеет смысл уменьшать пропускную способность выходов, предшевствующих выходу в лестничную клетку, перед входом в которую обычно и происходят скопления.
<< Во время вынужденной экстренной эвакуации следует увеличивать численность обслуживающего персонала для исключения задержек потока людей. С учетом этих особенностей возможна задержка оповещения отдельных зон для обеспечения безопасной эвакуации людей из здания. Запасные пути эвакуации можно задействовать при невозможности использования основных или для обеспечения необходимого времени эвакуации. При этом следует предусматривать дополнительные сигналы оповещения для обращения внимания людей на необходимость использования запасных путей эвакуации.
Использование обслуживаемого персонала при эвакуации называется практической отработкой плана эвакуации. К сожалению ГОСТ не предъявляет требований по отображению сценариев возможной эвакуации на плане.
Практические навыки при полноценной отработке плана эвакуации, когда перед обслуживающим персоналом и посетителями ставится нетривиальная задача, бесценны.
Все это называется комплексом организационно-технических мероприятий.
Понятия "запасной путь эвакуации" отсутствует.
<<Оценка безопасности эвакуации людей путем анализа соответствия расчетного и необходимого времени эвакуации из помещений показывает, что возможность предварительного уведомления о необходимости эвакуации обслуживающего персонала объекта, а затем людей, находящихся в зоне оповещения, в одном из помещений которой произошел пожар, существует, как правило, в течение не более 1 мин. Ввиду этого, подтверждение достоверности факта пожара с использованием обслуживающего персонала возможно лишь для включения системы jповещения других (соседних с зоной пожара) зон. Время для подтверждения достоверности факта пожара формируется за счет задержек оповещения с учетом особенностей распространения продуктов сгорания.
Я лично не нахожу правовых оснований для затрат времени на проверку достоверности факта пожара. При расчетах в существующих условиях в большинстве случаев нет этой одной свободной минуты, особенно в зданиях с проемами в перекрытиях (эскалаторы, лестницы 2-го типа). ОФП в этих зданиях могут наступать с разницей 0,5 минуты на различных этажах.
Задержка оповещения может быть только для выхода обслуживающего персонала на свою заранее отработанную при практической эвакуации точку.
<<Проводим разбивку пути эвакуации на зоны от эвакуационного выхода до наиболее удаленной зоны. Как правило, для эвакуации предусматривается не менее двух эвакуационных выходов. Поэтому направление движения выбираем в зависимости от места возникновения пожара
К такому выводу мы пришли еще раньше (см. выше). Необходимо добавить что дымоудаление должно быть организовано аналогично.
Необходимость таблицы № 1 под большим вопросом. Нужны ли временные задержки если каждая секунда на счету? На практике не бывает ПРЯМОУГОЛЬНЫХ в плане и в разрезе зданий.
<<При этом необходимо отметить, что оповещение зоны возникновения горения производится сразу по факту срабатывания СПС или обнаружения горения людьми.
Видимо терпения не хватило дописать:).
То есть как только я увидел очаг - сразу же сработала СОУЭ?
На практике люди не умеют нажимать на ИПР. Бывали случаи когда обслуживающие техники надрывали животы при виде работников банковских организации, тыкающих в знак (F10).
<<Если рассмотреть возможность возникновения пожара в любой из зон, то минимальное количество возможных сценариев по времени оповещения об эвакуации N можно оценить по формуле
N = n2 — n, (4)
где n — количество зон оповещения.
Каждая из таблиц 1 и 2 содержит n2 значений задержек оповещения. Цифровые индексы в формулах соответствуют номерам рассматриваемых зон.>>
Опять происходит привязка к таблицам. В одной зоне оповещения может и три выхода, и один выход, и десять.
Вот эта формула мне напоминает определение числа степеней свободы статически неопределимой многопролетной балки. Но нужна ли она?
<<Ложное оповещение всех людей в таком здании как Национальная библиотека (более 500) является республиканской чрезвычайной ситуацией по закону о защите населения и территорий от чрезвычайных ситуаций природного и техногенного характера.
Не понимаю я понятия "ложное оповещение", может все таки ложная сработка. Нет никаких оснований для траты времени на объекте с массовым пребыванием людей на проверку достоверности сигнала.
П.С. Дабы не путатся в подобных таблицах (дебрях) необходимо разбирать принципально разные планировки зданий, классифицировать их, а потом уже делать выводы по n2-n. |
| |
|
[31.07.2019 0:26:08] | | Это ж сколько нужно терпения и внимания чтобы такое реализовать. Аж восхищаюсь..Ув.adgernaut ® желаю успехов в творчестве.
По самой матрице. Мне кажется для удачного чтения не нужны PR/AL/ и т.д. непосредственно инсталлятору они ничего не скажут. По идее там нужна логика И/ИЛИ, задержка, указания о наличии блокировки (как для СПДВ, так и для АУПТ) что-то типа: "И0", "ИЛИ60", "И60х№№" |
| |
|
[31.07.2019 9:37:45] | | Viss ® [31.07.2019 0:26:08]
>>Это ж сколько нужно терпения и внимания чтобы такое реализовать. Аж восхищаюсь..<<
Спасибо за похвалу, а то с мотивацией что-то туго :-(
"Дорога в тысячу ли начинается с первого шага" (с) Лао-Цзы
>>По самой матрице. Мне кажется для удачного чтения не нужны PR/AL/ и т.д. непосредственно инсталлятору они ничего не скажут. По идее там нужна логика И/ИЛИ, задержка, указания о наличии блокировки (как для СПДВ, так и для АУПТ) что-то типа: "И0", "ИЛИ60", "И60х№№"<<
По атрибутам в перекрестьях по первым фидбекам я уже понял, что это не самый лучший вариант. Буду делать еще насколько примеров, там уже уберу все это в атрибуты зон/устройств, а в самом пересечении только крестики или точки. Надо еще подумать, как корректно в таком случае отображать блокировку. Пока в раздумьях.
Логику "И", "ИЛИ", если она где нужна (я пока кроме автоматизации насосной еще не придумал вариант), можно изобразить как у Siemens в их автоматике на контроллерах SIMATIC в виде подобной таблицы:
https://w3.siemens.com/mcms/process-...
Тоже пример для насосной в планах. |
| |
|
[31.07.2019 21:39:59] | | может, проще сделать комбинированную систему?
Сначала расписать сценарии, а потом в таблицу внести номер/номера через запятую на пересечении пожарной зоны/ элемента. |
| |
|
[01.08.2019 0:35:13] | | Способов изобразить алгоритм можно придумать бесчетное множество. Но почему я остановился именно на таком варианте в виде матрицы? Ответ простой - этот вариант самый эргономичный, на мой взгляд. Начнём с самой структуры таблицы - с ними мы приучаемся работать с начальных классов. Поиск информации в таблице максимально упрощен, структура проста. Таблица-матрица - типичный пример, который знаком также с детства это турнирная таблица. Тоже не долго объяснять никому не надо. Таким образом можно смело заявлять, что структура матрицы как таковой понятна всем получившим аттестат о среднем образовании.
Теперь встаёт вопрос, что можно сделать эргономичного, именно для людей, а не мифических "инженеров-интеграторов" или не менее мифических "инженеров проектировщиков автоматики ПДВ", с одной стороны снизить порог вхождения для работы с пожарной автоматикой для смежников, проверяющих, строительного и пожарного надзора, тех же наладчиков, а с другой стороны за счет доведения наиболее понятным образом до исполнителей основных задумок переместить центр принятия решений на более высокий уровень. Ну и высокая эргономичность снижает вероятность возникновения ошибки. Тут, как мне кажется, практически идеально подходит понятие "зона" (территориальная единица) как базис для такого описания. Если выделить на планах эти зоны, составив таким образом карту, то это становится понятно всем. На мой взгляд крайне важна в этом случае именно графическая составляющая. Графику человек схватывает за доли секунды - так уж устроен наш мозг. С одной стороны карта в виде схемы зонировния, с другой плоская структура в виде матрицы. С этим легко работать любому человеку. А что такое сценарий? По сути это псевдокод, который сложно разобрать. Куча усилий тратится на чтение "сценария", его осмысление, поиск в нем необходимой и ценной на текущий момент информации. С другой стороны, матрица не в состоянии предоставить абсолютно всю информацию, как и другие варианты описания. Тут уж приходится руководствоваться эмпирическим распределением Паретто необходимых усилий и получаемого результата. Многие наверное видели в интернетах выражение: "20% усилий приносят 80% результата". Пр близительно так и тут. Мы же не просто так на чертежах не отрисовываем извещатели в натуральную величину, а вместо них используем УГО. Ибо от того, что мы изобразим его "как есть" практически ничего не изменится за редким случаем (иногда это действительно требуется). Это тот самый живой пример отображения принципа Паретто (особенно, если чертить на кульмане, как в стародавние времена). Но вернёмся к нашим баранам. Еще один из вариантов базиса для матрицы - исполнительные устройства пожарной автоматики. Это немного сложнее чем "зоны" с картой, но после относительно небольшой подготовки с этим разберется любой монтажник. Вентилятор, он и на объекте "А" вентилятор, и на объекте "Б" тоже. Аналогично можно сказать про клапаны. Да, производитель, конструкция и принцип работы могут немного отличаться, но в целом то одно и то же. Сценарий же не такая универсальная штука, везде разный. О какой эргономике тут можно говорить.
Еще один немаловажный аспект эргономики матрицы, так это соблюдение строгой периодической структуры. Т.е. строки должны быть все одной ширины, столбцы одной ширины, в идеале - и строки и столбцы одной ширины. Вот попробуйте поиграть в игру "морской бой" с строками и столбцами разной ширины в разнобой. Думаю, игра с самого начала перестанет приносить удовольствие и превратится в пытку. Вместо того, чтобы сконцентрироваться на подбитии вражеского линкора ваш мозг будет постоянно цеплятся за нарушенную структуру игрового поля. Так и в любой таблице, если одно поле больше другого, оно кажется более важным. В случае пожарной автоматики сложно выделить наиболее важное поле - все должно просто работать без гвоздей. Именно по этим причинам содержание ячеек в пересечении должно отвечать следующим требованиям:
1. Иметь одинаковый размер - именно поэтому я и подразумевал только двухбуквенные обозначения;
2. Соответствовать ограниченному набору, который чем меньше, тем лучше;
3. Не нарушать структуру таблицы - поэтому под запретом текстовые пояснения в пересечении.
Если же в пересечении вписывать номера сценариев, то все эти эргономические преимущества нивелируются.
Похоже, все что я тут описал выше придется добавлять в руководство :-). |
| |
|
[01.08.2019 22:33:11] | | тогда еще проще - подробно расписать все элементы системы пожарной безопасности, до последнего клапана ОЗК, с вписыванием состояния в режиме Норма и в режимах Пожар по горизонтали и все пожарные зоны по вертикали.
Можно добавить для каждого элемента графу Внимание и Неисправность
Там, где должен включаться элемент в данной зоне - жЫрнИй-жЫрнИй точка.
Я так по требованию иностранной страховой компании делал перед сдачей довольно большого по этажности и площади объекта, портянка получилась приличных размеров.
Это еще снизит порог вхождения.
|
| |
|
[01.08.2019 23:07:15] | | >>подробно расписать все элементы системы пожарной безопасности, до последнего клапана ОЗК<<
Подробно расписывать все элементы может и надо, но только стоит ли вносить их все в матрицу? Если есть группа однотипных устройств, которые ведут себя абсолютно одинаково, то может стоит их вынести в отдельный список? Аналогично можно поступить с ЗКПС и списком датчиков в них.
>>Можно добавить для каждого элемента графу Внимание и Неисправность<<
А зачем это нужно? Если "Внимание" или "Неисправность" должны вызвать какую-то особую реакцию в автоматике, то наверняка надо выписывать. Если же только щёлкает обобщенное реле или загорается индикатор, то это не нужно. Эта информация избыточна в большинстве случаев, достаточно будет пары строк для этих обобщенных сигналов.
>>делал перед сдачей довольно большого по этажности и площади объекта, портянка получилась приличных размеров.
Это еще снизит порог вхождения.<<
Все верно, портянка с низкой эргономичностью на расширенном А0 не нужна никому. Поэтому надо максимально отрезать лишнее, при этом "с водой не выплеснуть ребёнка". |
| |
|
[02.08.2019 0:37:42] | | Большая портянка не всегда полезна. Иногда ее трудно читать. В этом случае имеет смысл иметь сноски или что-то типа звездочек, под которыми пойдут уточнения до конкретики. Вот туда и можно относить вся кучи исполнительных устройств, срабатывающих одновременно или при дополнительных условиях.
Сначала мы ищем лес, где вообще-то могут быть грибы. Потом мы ищем лес под конкретные грибы (белые!). Потом мы ищем ложбинки или косогорки, где четко могут быть белые. И уже потом на тех полянах ищем обетованное. Т.е. в несколько этапов. А вот ехать за три девять земель на конкретные ложбинки, это надо заранее их знать. |
| |
|
[02.08.2019 9:52:19] | | >>В этом случае имеет смысл иметь сноски или что-то типа звездочек, под которыми пойдут уточнения до конкретики.<<
Уважаемый ФПБ, в сносках как таковых в данном случае потребности нет. Для этого предусмотрены графы атрибутов, куда можно прописать ссылку на нужные листы.
У меня тут сейчас другая проблема крутится: как показать совместно действующие исполнительные устройства, действующие в рамках одной строгой последовательности, да еще при этом не замусорить матрицу. А может в этом и нет нужды особой.
И еще немножко по применению матрицы, как ее используют. Я вижу несколько вариантов использования:
1. Экспертная оценка. Для того, чтобы эксперт не утонул в дебрях подробностей информация должна быть представлена довольно компактно. Вот в экспертизе лежит проект и эксперту вдруг приспичило уточнить, закрываются ли клапана только в отсеке или на всем объекте (к примеру, на чертежах есть транзитный воздуховод с клапанами). Ага, тут ошибочка. Или посмотрел расчет вентилятора, он на один этаж, а по матрице сразу во всем отсеке все зоны этого вентилятора активны - другая ошибочка. Конечно, это все можно искать в тексте, но это так утомительно. Оптимальный размер таблицы - не больше А2 листа.
2. Пуско-наладочные работы. Тут наладчик спокойно может перебивать "дырочка в дырочку". В данном случае его и портянка на А0 не смутит, и куча ссылок на другие листы - все делается по порядку. С другой стороны и наладчику важно увидеть картину в целом, чтобы оптимально выполнить программы для ППКП и ППУ. Сколько я видел таких "программ", где все реализуется через одно место, что потом для внесения мелкого изменения приходится сидеть целый день и разбирать чужой "спагетти код". Чем думали эти люди, когда создавали сие я не знаю. Причём такое есть даже у одного сапожника, который со своими фирменными сапогами, матрица там не помогла. Уважаемый ФПБ, Вы должны догадаться про кого речь.
3. И еще один вариант - это уже проверки на вводе в эксплуатацию и уже в самой эксплуатации. Тут уже нужен чек лист. Саму по себе матрицу уже можно так использовать, но только отметки ставить негде. Для этого можно подготовить для каждой проверки отдельные листики, удалив из таблицы лишние строки и добавив поля для отметок. И опять же, требования к экономике снова появляются. При проверках больше всего времени тратится на поиск конкретной зоны защиты или исполнительного устройства. А чтобы быстрее это все найти нужно иметь хорошо отсортированный список. Как Вы верно заметили: сначала лес с грибами, потом с белыми грибами, а вот и заветная поляна. Ну и всякие разные аудиты, внутренние и внешние, проверки ГПН никто не отменял. Тут до полянок разбираются только в крайнем случае. Снова к первому пункту можно вернуться |
| |
|
[02.08.2019 20:43:31] | | Как раз для проверяющего предложенный мной вариант удобен.
Нас, когда fire marchal или как он правильно назывался, проверял, ему как раз было наглядно.
Запустили два извещателя в зоне - смотрит на АРМ, где и что активно по результату.
Хорошо нас тогда проверяли, от всей души. Почти день ушел и три баллончика спрея :) С вскрытием оросителей, и последующим пуском системы ПТ, причем в разных вариантах, включая проверку работы СПДЗ при отключении обоих вводов электроснабжения и запуске ДГУ |
| |
|
[02.08.2019 20:44:22] | | *смотрит и сравнивает с матрицей, достаточно пальцем вести сверху вниз и сразу видно, что есть что |
| |
|
[03.08.2019 0:36:32] | | Тимур без команды ® [02.08.2019 20:43:31
>>Как раз для проверяющего предложенный мной вариант удобен<<
Ну так если Вы прочитали бы руководство не по диагонали, то увидели бы, что это один из вариантов.
Но опять же, какой смысл втюхивать в матрицу все ОЗК, если они все разом закрываются при любом пожаре? Не проще ли вынести в отдельный список? |
| |
|
[08.04.2020 14:30:24] | | Уважаемый adgernaut, в начале дискуссии не слишком обратил внимание в Вашем примере матрицы на столбец "Архитектура". Подумал, зачем мне привязка к уровням безопасности SIL. Увидел, что для ручных извещателей и спринклерного тушения, в таблице архитектура 1оо1. Также в таблице встречаются архитектуры 1оо2, 2оо2, 2оо3.
Не могли бы Вы пояснить каким типам извещателей какие архитектуры присвоили, и корректно ли использование архитектур АСУТП для технических средств пожарной автоматики? |
| |
|
[08.04.2020 15:34:42] | | Предположу:
1оо2 - точечные ПИ;
2оо2 - термокабель;
2оо3 - сигнал "Пожар" берется с газового/порошкового АУПТ. |
| |
|
[08.04.2020 16:13:12] | | j_flack [08.04.2020 14:30:24]
>>Подумал, зачем мне привязка к уровням безопасности SIL. Увидел, что для ручных извещателей и спринклерного тушения, в таблице архитектура 1оо1. Также в таблице встречаются архитектуры 1оо2, 2оо2, 2оо3.
Не могли бы Вы пояснить каким типам извещателей какие архитектуры присвоили, и корректно ли использование архитектур АСУТП для технических средств пожарной автоматики?<<
Уважаемый j_flack, все что мы видели и видим в сводах правил по пожарной сигнализации по вопросу 1-2-3-4 - все это жалкая пародия на давным-давно проработанные подходы в промышленной автоматике. Можно, конечно, написать, что "с использованием алгоритма С для защиты от ложняков и дулированием на случай отказа извещателя", но куда короче и проще написать 2оо3 или 2оо4. Мало того, в последней версии проекта СП на СПС появился алгорит для пожаротушения с учётом отказа одного из двух извещателей. Так это схема 1oo2D. Как короче передать эти вещи в таблице я не знаю.
На счет корректно или нет решать не мне. Я считаю, что любой способ корректен, если он облегчает понимание и вводит однозначность. |
| |
|
[08.04.2020 17:37:43] | | Уважаемый adgernaut, нигде же не прописано, что 2 адресно-аналоговых извещателя в ЗКПС, работающие по схеме "или" - это такая-то архитектура системы безопасности технологического процесса.
А требование по наличию матрицы есть в проекте свода правил на СПС? |
| |
|
[08.04.2020 20:45:38] | | Товарисчи, остепенитесь. Я и так вместо реального проектирования систем занимаюсь бумажной возьней в духе "а правильно ли я понимаю пункт"...
Матрица нужна, но нужна максимально простая.
Сигнал ПС:
- запуск СОУЭ
- разблокировка СКУД
- откл. произв линий
- откл. Вентиляция
- закрытие ОЗК
- открытие клапанов на ДУ
- Вкл. ДУ зоны
- Вкл. Приток зоны.
Всё. А то какие-то долбоящеры в Болиде придумали матрицы на 100500 листов (у них то она автоматом вылупляется), а простые проектировщики потом голову ломают.
Сделайте как можно проще. Прям чтобы даже тупой понял.
|
| |
|
[08.04.2020 20:45:39] | | Товарисчи, остепенитесь. Я и так вместо реального проектирования систем занимаюсь бумажной возьней в духе "а правильно ли я понимаю пункт"...
Матрица нужна, но нужна максимально простая.
Сигнал ПС:
- запуск СОУЭ
- разблокировка СКУД
- откл. произв линий
- откл. Вентиляция
- закрытие ОЗК
- открытие клапанов на ДУ
- Вкл. ДУ зоны
- Вкл. Приток зоны.
Всё. А то какие-то долбоящеры в Болиде придумали матрицы на 100500 листов (у них то она автоматом вылупляется), а простые проектировщики потом голову ломают.
Сделайте как можно проще. Прям чтобы даже тупой понял.
|
| |
|
[08.04.2020 21:58:34] | | >>Сделайте как можно проще. Прям чтобы даже тупой понял<<
Согласен, нужно как можно проще.
Но на пром. предприятиии архитектуры из МЭК 61508-6 для любого КИПовца как азбука для первоклашки. |
| |
|
[20.10.2020 8:18:49] | | Уважаемый автор, есть ли продвижение в руководстве и примера матрицы? Хотелось бы увидеть.
Спасибо. |
| |
|
[20.10.2020 10:27:23] | | >>Уважаемый автор, есть ли продвижение в руководстве и примера матрицы? Хотелось бы увидеть.<<
Пока больших продвижений нет (небольшие правки, принципиально ничего не меняющие). Планирую к марту завершить еще две части, а дальше как карта ляжет. |
| |
|
[13.07.2022 10:57:51] | | Доброго дня!
И как карты легли?
Шикарный труд!
И не сочтите за наглость, хотя это она и есть ))).
Поделитесь:
ПР 001-13.220.99-СПА-КУ «Системы пожарной автоматики. Концепция управления.»
ПР 002-13.220.99-СПА-СЗ «Системы пожарной автоматики. Схемы зонирования систем противопожарной защиты.»
ПР 004-13.220.99-СПА-БС «Системы пожарной автоматики. Блок-схемы алгоритмов систем противопожарной защиты.»
ПР 005-13.220.99-СПА-ОА «Системы пожарной автоматики. Описание алгоритма работы системы пожарной автоматики.»
|
| |
|
[13.07.2022 15:00:12] | | Пока не легла карта. Не сдвинулось за два года, к сожалению. |
| |
|
| | | Дискусия закрыта |
|