Проект на систему технических средств безопасности можно сделать в самом разном виде.
Наиболее разумные документы, определяющие порядок проектирования таких систем - РД 78.36.003-2002 и приложение (пособие) к РД 78.145-93 изданные МВД РФ.
Так вот, поскольку к разряду систем безопасности относится и два геркона на дверях склада с дровами, и интегрированная система на 500 видеокамер и 600 считывателей на атомной станции, то проект на «систему» может быть исполнен в самых разных видах: от одной странички до 10 кубометров бумаги. Например, в качестве проекта допускается использовать «Акт обследования». Это документ, который составляется заказчиком и исполнителем во время совместного обследования объекта и в котором сразу, на глазок, указывается, где какое средство надо поставить и куда от них вывести индикацию. Монтажник затем по месту пригвоздит на стены (двери) датчики, подключит их на «прибор приемно-контрольный», смотает оставшийся кабель, и все будут счастливы.
В случае с атомной станцией, конечно, все несколько сложнее. Там не обойтись без многостадийного проекта. При этом вы обнаружите, что к системам безопасности можно применить несколько слабо совместимых серий ГОСТов.
Во-первых, поскольку система технических средств безопасности является частью слаботочных систем зданий и сооружений, к ней применимы ГОСТ серии 21 (система проектной документации в строительстве) и все СНиП (строительные нормы и правила), особенно касающиеся монтажа электрооборудования и систем автоматики.
Во-вторых, поскольку современные системы безопасности, как правило, являются весьма высокоавтоматизированными, к ним применимы ГОСТ серии 24 («Автоматизированные системы управления») и более поздняя и более общая серия ГОСТ - 34 (просто «Автоматизированные системы»).
В-третьих, если в состав системы входит программное обеспечение (а как иначе, если каждое рабочее место оснащено двумя-тремя компьютерами), то ваш проект в части программного обеспечения должен удовлетворять еще и ГОСТ серии 19 (единая система программной документации).
В-четвертых, поскольку создаваемая вами система безопасности является изделием (пусть выполненным в единственном экземпляре и собранном непосредственно на месте эксплуатации), к ней в полной мере относятся и ГОСТ серий 2 (единая система конструкторской документации) и 15 (система разработки и постановки продукции на производство).
Наконец, вскользь вопросы проектирования систем затронуты и в специализированных ГОСТах :
- ГОСТ Р 50776-95 (Системы тревожной сигнализации),
- ГОСТ Р 51241-98 (Средства и системы контроля и управления доступом),
- ГОСТ Р 51558-2000 (Системы охранного телевидения),
- ГОСТ Р 50571 (Электроустановки зданий).
Наконец, во многих случаях вам придется иметь в виду и ряд РД, изданных Гостехкомиссией (ныне реорганизованной во ФСТЭК) по защите информации.
Пользуйтесь ими, если они вам помогают (например, там обычно перечислены все разделы, которые вам надо не забыть написать), но не делайте из них культа. А если вам что-то не нравится - относитесь творчески, не забывайте, что большинство этих ГОСТов (в частности, диктующих использование уродского нечитаемого шрифта - у меня от него в глазах рябит) написаны в те времена, когда компьютеры были несбыточной мечтой. В этих ГОСТах приняты все меры, чтобы помочь проектировщику допустить поменьше ошибок при переписывании и перерисовывании из чертежа в чертеж одной и той же детали (ныне это делается просто распечаткой одной модели в разных видах). В этих ГОСТах приняты все меры, чтобы любой чертежник с минимальной усидчивостью мог начертить так разборчиво, чтобы после снятия трех синек чертеж еще можно было читать (ныне копирование файлов или их вывод на плоттер с разрешением в тысячи штрихов на дюйм позволяет куда меньше задумываться об этих проблемах).
А теперь главный миф. Думаете, в процессе проектирования принимаются принципиальные технические решения? Как бы не так. Основные решения были приняты, когда заключался договор с выбранным подрядчиком. Теперь в процессе проектирования будут лишь уточняться детали, и, вероятно, будут сэкономлены немалые деньги (основная стоимость системы лежит вовсе не в основном оборудовании, а в кабелях и прочих вспомогательных материалах), но основные решения будут те же самые, что и на предыдущем проекте, выполненном той же фирмой. Именно за то, что подрядчик смог выполнить схожий проект, его и выбрали. Что же удивительного, что он снова применит те же основные решения. Более того, если заказчик попытается настоять на внесении изменений, получится хуже, дороже и дольше, чем, если бы изменений и не пытались вносить. Дело еще и в том, что принятие принципиальных технических решений - очень трудоемкое дело. Однажды полученные, проверенные решения - они и должны копироваться многократно. Существенные изменения в основных решениях, например, смена основного оборудования, приведет к существенным изменениям во всех разделах проекта. А в результате вероятность допустить ошибку (или просто не оптимально рассчитать использование вспомогательных материалов) возрастает неимоверно.
Тем не менее, некоторая свобода выбора при проектировании есть.
Основное оборудование определяет функциональность системы. Точнее, ограничивает ее. Если основное оборудование, например видеокоммутатор, или контроллер СКУД, или система периметровой сигнализации что-то не может, скорее всего, никакими ухищрениями этого добиться не удастся. Например, если коммутатор видео не имеет средств ограничить права просмотра видеокамер конкретным оператором, то добиться сходного эффекта, конечно, можно, отключая питание «секретных» видеокамер при заступлении на дежурство оператора без соответствующего «допуска», но согласитесь, это похоже на вырезание гланд автогеном.
Однако обратное неверно. Если оборудование может реализовать некоторый функционал, еще не факт, что его реализовать удастся. Например, в описанном случае с видеокоммутатором, обеспечивающем распределение прав на просмотр видеокамер, - эту функцию не удастся реализовать, если использованы пульты управления, не поддерживающие регистрацию (ввод пароля) оператора, или вместо них использована система управления через компьютерную сеть, когда фактически команды от всех операторов приходят на коммутатор от одного и того же компьютера, и в результате операторы для коммутатора неразличимы.
Проектирование, в идеале, состоит из нескольких этапов. Формально (по ГОСТу) большинство этапов необязательны, и если проект небольшой, они, конечно же, не оформляются как отдельные этапы работ по договору, и не завершаются оформлением заключительных красивых документов. Однако, подобно тому, как тендер на выполнение работ всегда есть, даже если не называется таким словом (и фактически выглядит как личное посещение заказчиком потенциальных подрядчиков и переговоры с каждым по отдельности), так подобно этому и этапы проектирования всегда присутствуют. Это полезно помнить, даже если этап «эскизный проект» заключается в 20-минутном рисовании схем карандашом на обрывке упаковочной бумаги.
По ГОСТ 34.601 этапы проектирования автоматизированной системы таковы:
- формирование требований;
- разработка концепции;
- техническое задание;
- эскизный проект;
- технический проект;
- рабочая документация.
Согласно СНиП 3.01.01 в состав рабочей документации на этапе монтажа и пусконаладки должен войти комплект исполнительной документации.
Согласно ГОСТ 24.209 в состав рабочей документации на этапе «ввод в эксплуатацию» должна войти также эксплуатационная документация.
Разберем все это по порядку.
Первые три этапа - включая разработку ТЗ на проектирование - для небольших задач нередко выполняются в рамках переговоров перед заключением договора, причем бесплатно. Результатом является ТЗ, которое сразу идет приложением к договору. Они выполняются, как правило, совместно заказчиком и подрядчиком, ибо лишь заказчик может сформулировать чего он хочет, и лишь подрядчик может помочь перевести эти «хотелки» в четкие формулировки технических требований. Уже на этом этапе желательно, чтобы в переговорах участвовали не только менеджеры по продажам, но и инженеры-проектировщики.
Второй этап (также обычно неявно выполняется еще до заключения договора) - разработка концепции. Он тоже обсуждался выше, ибо в 99% случаев сводится к вопросу подходит ли типовая концепция, применяемая подрядчиком X для решения проблем заказчика Y.
Третий этап - формирование формального технического задания - иногда (к сожалению очень редко, только для сравнительно больших проектов) выполняется в рамках первого этапа работ уже по договору. Очень рекомендую и заказчикам и подрядчикам (то есть если даже заказчик не желает оплачивать написание ТЗ) - составить и согласовать (подписать у заказчика) возможно более подробное техническое задание. Это техническое задание в результате должно лечь в основу самого важного документа, каковым является Программа и Методика проведения приемо-сдаточных испытаний. При отсутствии такого документа в момент подписания заключительного акта и заказчик, и подрядчик будут себя чувствовать неудовлетворенными.
ТЗ и ПМИ, несомненно, будут дорабатываться в процессе проектирования, но любые изменения к ним должны быть согласованными в том же порядке, что и при подписании договора. Неожиданно вносимые заказчиком накануне сдачи новые требования могут вылиться в авральную сверхурочную работу сотен людей. Неожиданно обнаруженные заказчиком в момент сдачи свойства системы могут означать, что эта система ему бесполезна и деньги выброшены на ветер.
Следующие три этапа - эскизный, технический проект и рабочая документация. Эскизные проект выделяется отдельным этапом договора только на больших объектах, а случаи разделения технорабочего проекта на отдельно технический и отдельно рабочую документацию мне пока еще не встречались. Вероятно, это имеет смысл только в договорах ценой миллиард безусловных единиц и выше.
Эскизный проект должен содержать перечисление всего основного и существенной части вспомогательного оборудования, ориентировочное указание, где оно располагается, а также общие описания алгоритмов функционирования системы. В случае выполнения работ на основании «акта обследования», роль эскизного проекта исполняет тот самый «акт обследования», в котором сходу, во время осмотра объекта, заказчик и подрядчик совместно указали «в каких комнатах какие датчики предполагается разместить». А без рабочей документации в таком случае можно обойтись.
Технический проект должен в подробностях описывать структуру и алгоритмы работы системы, а рабочая документация - всю информацию, необходимую для поставки и монтажа системы. Обычно их объединяют в один технорабочий проект. Основные составные части - спецификация оборудования, ведомость материалов, чертеж установки (размещения) технических средств, план расположения проводок, таблицы соединений и подключений (кабельные журналы). В идеале, в состав РД должны входить и план развертывания, план проведения работ, график поставки материалов и оборудования под монтаж.
Исполнительная документация. Проект - хорошо. Хороший подробный проект - еще лучше. Однако то, что получится в результате, наверняка будет несколько отличаться от проекта. Хотя бы потому, что в процессе монтажа выяснится, что предполагаемая гипсокартонная перегородка оказалась несущей железобетонной плитой, а расположение перегородок и дверей, тщательно измеренное проектировщиками перед началом работы, почему-то за время проектирования изменилось (предельный случай, встречавшийся мне – когда, приехав на монтаж мы обнаружили, что 3-этажное здание, на которое нарисован проект, снесено, а рядом появилось новое 6-этажное, и хозяин, не смущаясь, предлагает нам «как-нибудь развесить все на первые 3 этажа нового здания»). Так вот исполнительная документация - это умное название для тех экземпляров проектной документации, на которых монтажники помечают сломанным фломастером «как они сделали на самом деле». В приличных случаях потом это переносится в Автокад или на кульман. В неприличных - исполнительная документация остается в головах монтажников, и выветривается оттуда через пару месяцев, так что в случае ремонта все кабели придется вызванивать заново.
