Формирование системы комплексной безопасности. Часть 1

Скачать

Часть 1

Предпроектное обследование объектов и разработка технического задания

   Алексей Омельянчук. Нач. КБ Рубикон ООО «СИГМА-ИС».

Термин "техническое задание" (ТЗ) в приложении к системам комплексной безопасности (СКБ), к сожалению, не очень четко определен. Существующие стандарты описывают это понятие по-разному для разных отраслей, а нормативные документы из области противопожарной или противокриминальной безопасности усиливают это разнообразие

Процесс разработки технического задания на комплексную систему ТСБ бывает разным. Вот примеры из жизни.

Обследование различных объектов

1. Маленький магазинчик. В полном согласии с РД78. 36.003-2002 "Инженерно-техническая укрепленность. Технические средства охраны. Требования и нормы проектирования по защите объектов от преступных посягательств" задание делается за полчаса в форме акта обследования. Владелец магазина и представитель вневедомственной охраны (или инженер из монтажной организации) обходят помещение, качают головами, глядя на фанерные двери, и составляют акт, в котором прописывают, что владелец магазина усилит стены металлическими решетками, сейф приварит к заложенной в бетон арматуре, а в качестве "комплексной" системы будут установлены три ИК-пассивных датчика для обнаружения проникновения и б пожарных дымовых датчиков.
2. Небольшая АЭС. Ситуация прямо противоположная, но по сути похожая. В соответствии с рядом приказов МинАтома ТЗ создается по накатанной дороге - анализ угроз, теоретическое обоснование предлагаемых мер защиты, разработка концепции и структуры системы, предложения по организации рубежей защиты и их оснащению техническими подсистемами и т.д. Кстати, стоит отметить, что состав рубежей и рекомендации по их оснащению также зафиксированы в соответствующих нормативных документах, так что проведение этапа "анализ угроз" практически никак не сказывается на результате. ТЗ фигурирует на этапе, предшествующем проектированию отдельных подсистем.

Сам процесс разработки ТЗ заслуживает отдельного контракта на несколько миллионов рублей и занимает от нескольких месяцев до года. Как и в первом случае, ТЗ содержит перечень рубежей и помещений (территорий) с весьма подробным указанием какими средствами их необходимо оснастить.

Обратите внимание. Два, казалось бы, предельных случая - ларек на 2 м² и АЭС, но в обоих случаях ТЗ фактически содержит в себе ответ на самый сложный вопрос - какие системы (и даже какие элементы этих систем) нужны на этом объекте.

После принятия этих основных решений дальнейшее проектирование - работа чисто техническая.

Хоть и говорится, что "проект и технико-экономическое обоснование - это синонимы", на самом деле если и есть в проекте обоснование выбора оборудования, то лишь из ряда аналогичного.

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

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

Нормативные документы

Какова процедура проектирования системы, устанавливаемая существующими нормативными документами?

Наиболее подробно значение и содержание ТЗ излагается в стандартах серии 34 (автоматизированные системы). Однако в ней описывается очень многоступенчатая последовательность: 1-й этап -формирование требований; 2-й этап -разработка концепции; 3-й этап - формирование ТЗ; 4-й этап - эскизный проект и так далее.. Собственно ТЗ является результатом 3-го этапа работ. Эти стандарты разработаны еще в социалистическое время и подразумевают плановое хозяйство.

На каждую стадию оформляется отдельный договор, нередкое разными подрядчиками. Основная проблема при таком подходе ярко описана А. Райкиным - "Кто сшил костюм?" Вторая проблема не менее сложна: если организация-проектировщик меняется при переходе к следующему этапу, то неизбежно теряется 90% информации, накопленной предыдущим проектировщиком. Ведь невозможно вместить в отчет или ТЗ все, что было очевидно при обследовании, но оказалось по меньшей мере спорно при дальнейшем проектировании. Наконец, практически невозможно обновить концепцию, если при дальнейшем подробном проектировании выясняется необходимость внести некоторые изменения (просто потому, что договор на разработку концепции завершен и деньги на его финансирование закончились, а кто же будет что-то делать "за бесплатно"...).

В большинстве же случаев (для объектов стоимостью от 100 000 руб. до 100 млн руб.) при разработке систем безопасности фактически объединяются этапы разработки концепции, ТЗ и собственно проектирования, а документ "тех-задание" соответствует "исходным требованиям" в терминах ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания".

Обратите особое внимание - поскольку нет никаких иных нормативных документов, ТЗ на создание системы безопасности, вероятно, будет проверяться на соответствие ГОСТ 34.602 Однако если ТЗ создано до подписания договора, то есть его создание не оплачивалось явно, оно заведомо не может содержать требуемую информацию и, как правило, лишь внешне соответствует требуемой структуре.

Ведомственные документы
Эта следующая группа нормативных документов разработана ФГУ НИЦ "Охрана" МВД и ФГУ ВНИИПО МЧС России.

В большинстве случаев они напрямую диктуют "что необходимо установить", дабы снизить зависимость результата от квалификации проектировщика.

В частности, основополагающий документ -НПБ 88-2001 "Установки пожаротушения и сигнализации. Нормы и правила проектирования"-вообще не содержит термина "техническое задание". Фактически им являются сами НПБ.

Нормативные документы по охранным системам - это, в первую очередь, РД серии 78, разработанные НИЦ "Охрана".

Формально эти документы должны применяться только к объектам, за безопасность которых отвечает вневедомственная охрана. Тем не менее, из-за отсутствия других, они широко применяются любыми заказчиками - как частными, так и государственными.

К обсуждаемому вопросу напрямую относятся РД 78.36.003-2002 и РД 25.952-90 "Системы автоматического пожаротушения, пожарной, охранной и охранно-пожарной сигнализации Порядок разработки задания на проектирование". Второй из них устанавливает именно требования к составу ТЗ, при этом явно предполагается, что (цитирую) "задание на проектирование составляет организация-заказчик с привлечением организации-разработчика". То есть предполагается одноэтапный процесс проектирования, когда заказчик готовит ТЗ и в результате получает от исполнителя готовый комплект рабочей документации для проведения строительно-монтажных и пусконаладочных работ. Неудивительно, что рекомендуемый состав документа весьма далек от требований ГОСТ 34.602 и представляет собой в основном таблицы-вопросники для сбора исходных данных.

Первый же из упомянутых документов - РД 78.36.003 - рекомендует для простейших объектов практику создания систем без проектирования на основе так называемых актов обследования, когда все проектные решения принимаются по образцу типовых проектов непосредственно во время обследования объекта по согласованию с заказчиком. Используя термины ГОСТ 34, можно сказать, что акт обследования объединяет в себе результаты этапов "обследование", "создание концепции", "разработка ТЗ" и, пожалуй, даже "эскизный проект".

Важно отметить, что не существует единого подхода к процессу проектирования, а следовательно, и к содержанию ТЗ.

Полезный совет: поскольку применение большинства упомянутых документов спорно, лучше указать в ТЗ, какие нормы должны быть выполнены безусловно (в частности, НПБ), от каких допускаются согласованные отклонения В отношении других нормативных документов распространена формулировка "с учетом требований РД такого-то и такого-то". Это по идее обязывает проектировщика как минимум упомянуть, какие требования этих документов учтены, а какие проигнорированы.

Евростандарты
При составлении ТЗ на проектирование системы безопасности широко распространена практика подробного перечисления видов и количества оборудования, которое необходимо смонтировать. Это типичная ошибка, хотя ее происхождение вполне понятно - такой способ показать, чего вы хотите добиться, кажется простейшим На самом деле расчет точного количества оборудования - задача следующего этапа (проектирование).

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

Например, так: "в торговом зале необходимо обнаруживать несанкционированно проникших туда лиц в нерабочее время".

В отечественной практике более распространен термин "зрительные задачи" или "целевые задачи видеоконтроля" (Р-78.36.008-99 "Проектирование и монтаж систем охранного телевидения и домофонов. Рекомендации".

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

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

В последние годы для европейских нормативных документов (например, PRO 2005. The Regulatory Reform (Fire Safety) Order 2005) характерен постепенный отход от повествовательного описания "что необходимо сделать" и переход к описанию требований "как должно быть обосновано то, что будет сделано". Одна из причин этого состоит в том, что сейчас вполне доступна качественная аппаратура для обеспечения безопасности.

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

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

В Европе за последние годы в полный рост встала еще одна проблема: системы, разработанные и изготовленные в соответствии с нормами через несколько лет (вследствие небрежной эксплуатации или изменившихся условий) перестают обеспечивать решение поставленных задач. Английские законодатели приняли решение пойти по пути, похожему на стандарты системы управления качеством серии ISO 9000. Начиная с 2008 г. в Великобритании отменены сертификаты пожарной безопасности, которые ранее выдавались всем зданиям. Отныне требуется иметь не просто систему технических средств, соответствующую нормативам до какой-то даты, а документированные процедуры регулярного анализа возможных угроз и соответственной коррекции мер противодействия им. Это заставляет не бездумно вкладывать деньги в железо, а подключать мозги к анализу постоянно изменяющихся условий.

Новый отечественный ТР № 123-ФЗ по пожарной безопасности вводит требования,перекликающиеся с европейскими - требования декларирования пожарной безопасности. Эта декларация и должна содержать в себе соответствующие расчеты возможных рисков, обоснования выбора систем защиты, и ее необходимо регулярно обновлять.

Контроль выполнения заданий

Задание без контроля результата - это просто благое пожелание. Каким образом осуществляется контроль? Оптимально - в приближенной к реальной ситуации, с имитацией предполагаемых действий противника. Однако большинству гражданских организаций несколько накладно проводить масштабные "учения". И тут мы встречаемся со следующей причиной, почему часто в ТЗ сразу пишут количество и тип оборудования, которое необходимо поставить, смонтировать и подключить - выполнение такого задания, по крайней мере, легко проверить. Всем удобно, лишь страдает безопасность объекта - ведь все основные решения (состав системы) приняли при составлении ТЗ, и их почти невозможно изменить, даже если на этапе проектирования станет очевидной ошибочность этих решений.

Выход есть. Британские нормативные акты рекомендуют указывать и исходные требования, и способы их контроля в терминах пользовательских задач. Например, для противопожарной системы нужно будет перечислить вероятные причины возникновения пожара и те ценности, которые должны быть спасены системой пожаротушения. Разумеется, контроль проводится не с помощью имитации пожара, а расчетным путем - нормативы вроде наших НПБ у них тоже есть. Для охранной (противокриминальной) системы необходимо задать требования по обнаружению. Методика контроля также типовая - по имитации вторжения, выборочно в отдельных зонах контроля.

Для более сложных систем детальную методику проверки может и должен разработать проектировщик системы (это обязательно следует отразить в задании на проектирование), ведь для проверки придется имитировать нестандартные ситуации - например, чтобы не ломать входную дверь надо будет отпереть ее, хотя помещение находится на охране, и так далее... Обратите внимание, проверять следует не "все датчики", а "все зоны контроля". Если в задании сформулировано, что должно обнаруживаться движение в таком-то помещении, то и надо проверять, что тревога происходит при движении во всем помещении, особенно в углах и прочих сомнительных местах, а уж сколько при этом срабатывает датчиков и сколько их там установлено - это вопрос к проектировщику.

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