Долгие годы вопрос документирования взаимодействия различных противопожарных и других инженерных систем оставался не освещенным в нашем законодательстве и стандартах. Данная же статья призвана дать ориентир проектировщикам, их заказчикам и сотрудникам служб эксплуатации, каким образом этот вопрос решить, используя с одной стороны передовой, а с другой — уже хорошо проверенный на практике инструмент. Речь здесь пойдет о таком документе, который на жаргоне вовлеченных в пожарную безопасность специалистов называется «пожарная матрица» (fire matrix). Разумеется, в официальных документах она фигурирует под другими формальными названиями, о чем здесь также будет сказано. «Пожарная матрица» подходит для описания взаимодействия элементов противопожарной защиты между собой и смежными инженерными системами зданий. Она пригодна как для проектной и рабочей документации, так и на последующих этапах жизненного цикла противопожарных систем.
Постановлении Правительства № 87 [1] в статье 26 к) содержатся всем известные требования:
«Раздел 9 «Мероприятия по обеспечению пожарной безопасности» должен содержать: в текстовой части
<…>
к) описание и обоснование необходимости размещения оборудования противопожарной защиты, управления таким оборудованием, взаимодействия такого оборудования с инженерными системами зданий и оборудованием, работа которого во время пожара направлена на обеспечение безопасной эвакуации людей, тушение пожара и ограничение его развития, а
также алгоритма работы технических систем (средств) противопожарной защиты (при наличии);
<…>»
Проектировщики решают эту задачу банальным перечислением взаимодействующих систем (отключается то-то, включается то-то), иногда вставляют цитаты из СП 5.13130 [2] и СП 7.13130 [3], что-нибудь вкручивают про время работы, опережающее включение и т.п. Честно говоря, это все похоже на курсовую работу нерадивого студента — переписываются известные положения, определенные в существующих ГОСТ и СП, а нужны примененные на конкретном объекте решения. Но и проектировщика понять можно — на стадии проектирования у него недостаточно информации, надо взаимодействовать с множеством смежников непонятно каким образом, а сроки вот они — уже на следующей неделе надо относить в экспертизу. И максимум на что хватает времени, так это сделать выкопировку из проектов коллег. Далее на стадии выполнения рабочей документации, которую могут делать уже совсем другие люди из других фирм, ни о каком взаимодействии инженерных систем (даже в рамках противопожарных) уже нет и речи, вплоть до наладки и ввода в эксплуатацию. И очень повезет, если на объекте в это время будет специалист, который достаточно хорошо разбирается во всех вопросах пожарной сигнализации, противодымной вентиляции, оповещения, пожаротушения и т.д. А если такого человека не будет, то все ляжет на плечи специалиста по пуско-наладочным работам с совершенно непредсказуемым результатом.
В отечественных нормативных документах и стандартах требования к описанию алгоритма можно найти в РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» [4]. Ну и чем системы противопожарной защиты не автоматизированные системы? Думаю, можно здесь найти что-то полезное. Тем более, что любимое многими ввиду отсутствия альтернатив пособие к СНиП 2.08.02-89 [5] ссылается на предшественника этого документа — ГОСТ 24.211-82 [6]. Очевидно, что эти документы предъявляют достаточно общие требования, что для пожарной автоматики будет избыточно. Если же попробовать вычленить основные моменты, то для описания алгоритма необходимо привести следующую информацию:
Стоит обратить внимание, что «алгоритмом должны быть предусмотрены все ситуации, которые могут возникнуть в процессе решения задачи»
п. 7.1.7.1 [4]. Давайте определимся, что в случае пожарной автоматики подпадает под перечисленные выше позиции, которые необходимо определить в описании алгоритма.
Массив входных сигналов — в нашем случае это извещение «ПОЖАР» от определенной зоны контроля пожарной сигнализации (ЗКПС) или установки пожаротушения, которая принимается за отдельную ЗКПС. И эта зона контроля не просто логическая единица, а привязанная к местности, т.е. имеющая определенные границы территория. Таким образом, входные данные определяются в виде перечисления ЗКПС с их привязкой к местности на планах.
Перечень формируемых сигналов — это перечисление активируемых противопожарных систем и связанных с противопожарной автоматикой инженерных систем (СКУД, ОВиК и т.д.). При этом в большинстве случаев эти системы действуют также локально, а не по всему объекту. Система противодымной вентиляции должна запуститься только в определенных помещениях определенного этажа, пожаротушение также активируется строго по тем направлениям, где это необходимо. В итоге для извещения «ПОЖАР» от любой ЗКПС должен быть сопоставлен набор зон противопожарной защиты, также с привязкой к местности на планах.
Алгоритмы решения — помимо связывания входных и выходных сигналов для большинства систем противопожарной защиты мало получить только итоговое решение в виде включенных систем. Их включение должно также производиться в строгой последовательности в соответствии с технологическими требованиями. К примеру, газовое пожаротушение должно запускаться после включения светового и звукового оповещения о начале тушения, окончании эвакуации людей из защищаемого помещения, закрытия клапанов и дверей (герметизация помещения). Вентилятор дымоудаления из состава противодымной вентиляции желательно запускать после открытия клапанов, а компенсацию включать по истечении небольшой задержки после выхода на рабочий режим ДУ. Оповещение же может производиться в определенной последовательности: зона за зоной для исключения давки на путях эвакуации [12]. Многие из этих моментов хорошо описываются блок-схемами по ГОСТ 19.701-90 [7] и временными графиками (например, диаграммы Гантта [8]).
Несмотря на всю обстоятельность подхода в РД 50-34.698 [4] (разработанного в поддержку серии стандартов ГОСТ 34, содержащей требования к созданию автоматизированных систем), он все же очень сложен для понимания, и тем более не способствует формированию единообразного подхода у разных проектировщиков. Поэтому, прежде чем изобретать велосипед, имеет смысл рассмотреть подходы в иностранных и международных стандартах. И первое, за что тут цепляется глаз — это таблица из NFPA 72 [9] (табл. 1).
Таблица 1. Типовая матрица входов/выходов из NFPA 72
Давайте взглянем на нее повнимательней и определим, все ли необходимое в ней представлено. Итак, во входных данных имеем перечисление зон контроля пожарной сигнализации (или их групп). Их текстовое описание дает вполне четкое, хотя и не совсем однозначное представление о территориальной привязке. Результаты решения здесь определены практически в полном объеме. Тут также есть необходимость дополнить пространственной привязкой зоны действия противопожарных систем. Алгоритм решения задачи по данной таблице самый элементарный: ищем пересечение нужных нам строк и столбцов, и если там стоит отметка, то система активна при сигнале от данной ЗКПС. Но не нашлось здесь места для описания последовательности действий при пуске СПЗ. Не отражено решение задачи, когда сигналы поступают от нескольких ЗКПС, что может быть критично для систем противодымной вентиляции.
К счастью, с этими вопросами помогает разобраться недавно увидевший свет стандарт IEC 62881-2018 «Cause and effect matrix» [10], разработанный в поддержку стандартов по функциональной безопасности. В нем для описания взаимодействия систем противоаварийной защиты предлагается использовать аналогичную таблицу — причинно-следственную матрицу (табл. 2). И здесь уже представлен механизм, где через ссылки на другие листы или документы таблицу можно дополнить всеми необходимыми данными: планами зонирования, структурными схемами, блок-схемами алгоритмов и временными графиками. Таким образом, совместив подходы NFPA 72 [9] и IEC 62881 [10], получаем удовлетворяющий требованиям РД 50-34.698 [4] документ, содержащий описание алгоритма. Для решения задачи с двумя входными сигналами в концепции IEC 62881 [10] можно предусмотреть блокировки, например, для запрета открытия клапанов дымоудаления более чем в одной зоне с общим вентилятором. На более глубоком и системном уровне подходы к составлению причинно-следственной матрицы для противопожарных систем проработаны в Ассоциации немецких инженеров и представлены в документе VDI 6010 Blatt 1 [11].
Таблица 2. Пример причинно-следственной матрицы из IEC 62881 с ссылками на дополнительные документы
«Пожарная матрица» — жаргонное название причинно-следственной матрицы (ни в коем случае не путать с причинно-следственной диаграммой, также известной как «рыбий скелет» и «диаграмма Исикавы»), используемой для описания взаимодействия противопожарных систем.
Специалисты, которые изучали иностранные стандарты, могут подумать, что такого термина как «пожарная матрица» в иностранных стандартах не встречается. В целом это так, обычно же в официальных документах употребляются термины «Cause and Effect matrix», «Input/output matrix», «С&E» или вовсе «Cause and effect». И данное устойчивое словосочетание при переводе просто не замечается — подумаешь, какие-то «причины и следствия». Но в таком виде в англоязычных стандартах «пожарную матрицу» можно найти в следующих документах:
«Пожарная матрица» упоминается под терминами «Verknupfungsplan (Brandfal lmatr ix)» в VdS 2095: 2010 «Richtlinien fur automatische Brandmeldeanlagen. Planung und Einbau». В других документах на немецком языке она иногда упоминается как «Brandfallsteuermatrix».
Одна из существенных проблем при разработке и описании алгоритма работы противопожарных систем — это необходимость установления взаимосвязей между различными технологическими системами. Системы оповещения, пожарной сигнализации, противодымной вентиляции, пожаротушения в большинстве случаев проектируются разными людьми, нередко из разных организаций. Для этих систем используются различные подходы и терминология, что вызывает основательные затруднения при попытках осуществить корректную автоматизацию. Особенно это касается противодымной вентиляции — не просто так наличие причинно-следственной матрицы является обязательным в документации согласно BS 7346-8. С многозональными системами оповещения тоже не все просто, и требования к такой таблице есть как в уже упомянутом ранее пособии к СНиП 2.08.02-89 [5], так и в британском BS 5839-8. И для междисциплинарного взаимодействия «пожарная матрица» подходит как нельзя лучше, т.к. она позволяет абстрагироваться от технологических особенностей без привязки к конкретному оборудованию и производителю, чего нельзя сказать о таблицах программирования.
На разных стадиях жизни комплекса СПЗ может требоваться различная детализация алгоритма. На предпроектной стадии (концепции) нужна информация в общих чертах, крупными мазками. На стадии проектирования уже определяются основные параметры: размеры зон СПЗ, алгоритмы принятия решения о пожаре, варианты минимизации последствий от ложных срабатываний и т.п. А на стадии рабочей документации появляется полный перечень ЗКПС, исполнительных устройств и связанных с ними выходов прибора управления. В данном случае «пожарная матрица» может быть легко использована с самого начала, постепенно обрастая дополнительной информацией. К примеру, на стадии предпроектной концепции с группой зон «5 этаж» связывают дымоудаление на этом же этаже, создание избыточного давления в наземных незадымляемых лестничных клетках и зоне безопасности, обустроенной в лифтовом холле. На стадии проектирования и выпуска рабочей документации могут быть выявлены дополнительные зоны, например с газовым пожаротушением, а система противодымной вентиляции может предусматривать несколько режимов работы (к примеру, для офисов открытой планировки или кабинетной системы потребуются вентустановки разной производительности). И этими данными легко дополнить составленную ранее пожарную матрицу. К моменту производства пуско-наладочных работ в пожарной матрице можно отразить всю необходимую информацию так, что она не будет уступать по информативности таблицам программирования. И это не потребует от проектировщика глубоких знаний конкретного применяемого оборудования, не придется каждый раз заново переучиваться.
Уже на этапе приемки «пожарная матрица» может быть приложена к программе комплексных испытаний, что избавит от кучи рутинной работы по составлению этого документа. А вот на стадии эксплуатации снова понадобится «пожарная матрица» с малой детализацией для удобства руководящего состава, которому некогда вникать в детали вплоть до каждого устройства, и для внешних проверяющих — инспекторов и аудиторов. Матрица с глубокой детализацией остается уделом инженеров по техническому обслуживанию.
«Пожарная» или причинно-следственная матрица — отличный инструмент для описания взаимодействия противопожарных систем. Ее преимущества:
Широкое применение «пожарной матрицы» — скорее вопрос времени. И тут не важно, будут ли ее требовать своды правил или ППР. Это настолько удобно, что стоит только раз попробовать, и уже сложно будет отказаться от использования этого инструмента. Главное научиться «правильно готовить» эту матрицу в зависимости от ситуации, не перенасыщая ее ненужной информацией. И вот тут не помешали бы методические рекомендации или ГОСТ, которые в общих чертах описали бы требования к оформлению матрицы, как это сделано в VDI 6010 Blatt 1 и IEC 62881.
Хотелось бы выразить надежду, что данная статья не останется незамеченной и поспособствует более широкому применению этого прекрасного инструмента или даже сподвигнет профильные ведомства к более глубокой проработке вопроса, как это сделала Ассоциация немецких инженеров с выпуском соответствующих директив.
1. Постановление Правительства РФ от 16.02.2008 № 87 «О составе разделов проектной документации и требованиях к их содержанию».
2. СП 5.13130.2009 «Системы противопожарной защиты. Установки пожарной сигнализации и пожаротушения автоматические. Нормы и правила проектирования».
3. СП 7.13130.2013 «Отопление, вентиляция и кондиционирование. Требования пожарной безопасности».
4. РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».
5. Пособие к СНиП 2.08.02-89 «Проектирование систем оповещения и управления эвакуацией людей при пожарах в общественных зданиях».
6. ГОСТ 24.211-82 «Система технической документации на АСУ. Требования к содержанию документа «Описание алгоритма»».
7. ГОСТ 19.701-90 «Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения».
8 Диаграмма Гантта. Википедия. URL: .
9. NFPA 72-2019 «National Fire Alarm and Signaling Code».
10. IEC 62881-2018 «Cause and effect matrix».
11. VDI 6010 Blatt 1 «Sicherheitstechnische Einrichtungen fur Gebaude — Systemubergreifende Kommunikationsdarstellungen».
12. Холщевников В.В. Проблема беспрепятственной эвакуации людей из зданий, пути ее решения и оценки // Алгоритм безопасности. 2006. № 4.
Ерёмин Николай Николаевич, ведущий инженер ООО «Альянс «Комплексная безопасность»
Статья опубликована в журнале "Алгоритм Безопасности" № 1, 2019 год
Другие статьи
Противопожарные нормы в США, Европе и России