Скачать статью в формате Word
Сразу оговоримся — эта статья не предназначена для людей, свободно оперирующих понятиями ЕСКД и ГОСТами 34.ХХХХ и 19.ХХХХ серий. Статья ориентирована на людей, не умеющих писать ТЗ (Техническое Задание).
Для чего нужно ТЗ.
Рассмотрим примитивную ситуацию: вы купили дом и собаку для охраны… собаке надо где-то жить, а значит, нужна конура. Казалось бы, все просто. Пришел профессиональный строитель собачьих домиков дядя Вася, за пару дней соорудил будку с цепью и приглашает вас принять работу. Вы приходите, и что вы обнаруживаете? Будка построена «летняя», а собака должна жить круглый год, вход в конуру расположен со стороны двора, а вам бы хотелось, чтобы собака смотрела на ворота, цепь не дотягивается до сарайчика, а там хранятся ваши ценные садовые инструменты и техника. В общем, деньги потрачены зря, вы недовольны, дядя Вася не понимает, в чем он виноват, так как сделал все по его разумению отлично. А проблема была в отсутствии Технического Задания…
Системы безопасности, о которых пойдет речь, во много раз сложнее конуры для собаки, и, тем не менее, процессы написания ТЗ будет похожи. В ТЗ должны быть однозначно определены такие моменты, как
- цель создания системы (назначение системы);
- технический объем работ;
- требования к системе в целом;
- требования к отдельным подсистемам;
- прочие требования.
Данное разбиение носит условный, хотя и проверенный временем порядок.
Рассмотрим подробнее каждый из разделов ТЗ.
Цель создания системы.
В данном разделе обозначается, собственно, основная причина для создания системы, например: предотвращение воровства имущества, в том числе, инструментов и урожая, находящегося на территории частной собственности заказчика. Или: повышение защищенности объекта путем создания интегрированной технической системы безопасности. Цель может быть изложена и более развернуто, однако, чаще всего, для этого используются последующие разделы ТЗ.
Далее, имеет смысл описать, собственно, ваш объект и те участки объекта, которые вы хотите защищать (так называемые локальные зоны).
К примеру: Объект представляет собой участок в городской застройке, огороженный по периметру бетонным забором с воротами и калиткой. На участке расположен одноэтажный жилой дом и хозяйственные постройки.
Или: Объект состоит из следующих зданий и сооружений: офисное здание №1, 3 этажа, кирпичная постройка, имеет центральный вход и пожарный эвакуационный выход. Соединено с офисным зданием №2 закрытой галереей на уровне 2-го этажа. Офисное здание №2 8 этажей, имеет 4 пожарных эвакуационных выхода. Пятый и шестой этажи — ВИП, доступ ограничен.
Как показывает опыт, любой объект может быть описан таким образом, чтобы в дальнейшем не возникало разногласий по поводу обозначения того или иного строения или значимой его части (цеха, отдела, этажа, помещения и т.п.). Объект стоит разделять на локальные зоны охраны, особенно, если они будут оснащаться различными системами, или должны иметь различные степени защиты.
Например, при описании объекта «банк» имеет смысл заострять внимание на таких помещениях, как «касса», «хранилище», «операционный зал», «банкомат» и т.п. так как подобные помещения будут существенно отличаться по степени защиты от всех остальных. При наличии на объекте периметра большого размера, имеет смысл выделить в отдельные зоны все имеющиеся ворота и калитки, так как их оснащение будет существенно отличаться от оснащения забора (разумеется в случае, если вы ими пользуетесь), а также разбить периметр на рубежи, если предусмотрены различные способы охраны различных участков. А вот разделять на отдельные зоны 6 этажей офисного здания, оснащаемых по одному принципу, смысла не имеет.
В этом же разделе целесообразно указать, из каких конкретно подсистем будет состоять ваша система безопасности.
Технический объем работ.
В данном разделе описывается, что же конкретно нужно сделать в рамках создания системы. А именно: примерно описать, какую локальную зону (обозначенную в предыдущем разделе) какими средствами каких подсистем надо защитить. При этом не обязательно (и даже нежелательно) загромождать этот раздел сложными техническими описаниями устанавливаемых устройств или указывать количество видеокамер на периметре с точностью до единицы, или, тем паче, обозначать фокусное расстояние объектива, или высоту размещения считывателя. В ТЗ вообще, по возможности, не должны фигурировать конкретные марки оборудования и жесткие параметры (кроме случаев, вызванных необходимостью соблюдения, например, климатических требований, но об этом чуть позже). В данном разделе максимально описываются ваши «хотелки» — то самое, на основании чего грамотный исполнитель и составит вам спецификацию и/или изготовит проектную документацию.
В качестве примера: допустимо писать, что «установленные на периметре видеокамеры должны обеспечивать распознавание лица нарушителя, пересекающего забор на любом участке периметра» Или: «размещение телевизионных камер должно обеспечивать сплошную полосу наблюдения и исключать «мертвые» зоны на этой полосе». Или: «на въезде/входе на территории локальных зон оборудовать проходные шлюзового типа для прохода персонала. Проходные должна быть оборудованы элементами СКУД (магнитоконтактными датчиками положения дверей, считывателями магнитных карт, электромагнитными замками) и элементами СВН, позволяющими однозначно идентифицировать проходящий персонал». И такие формулировки будет правильнее, чем, «установить на всей протяженности периметра 29 видеокамер с фокусным расстоянием 6мм» или «установить поясной турникет марки ХХХ, с двумя считывателями YYY, на высоте 1,2 м, а также две видеокамеры на вход и на выход на расстоянии 6 м от прохода, на высоте 3 м». Вы можете, конечно, выполнить львиную долю работы исполнителя, продумав за него, какое оборудование и в каких конкретно конфигурациях вы собираетесь использовать, но при этом:
- будьте готовы, что ваши ошибки по подбору оборудования будут исправляться за ваш счет или не будут исправляться вовсе;
- вполне возможно, что, используя подобранное вами оборудование, целей создания системы вы так и не достигнете.
Задача заказчика определить «что», а задача исполнителя предложить «как».
Требования к системе в целом.
Если обратиться к нормативной документации, то в данном разделе вы найдете массу требований, таких как:
- требования к безопасности эксплуатации технических средств;
- требования по эксплуатации, удобству технического обслуживания, ремонта и хранения;
- требования по транспортабельности;
- требования к возможности модернизации;
- требования по эргономике к рабочим местам;
- требования к надежности;
- требования по стандартизации и унификации;
- требования к сырью, материалам и комплектующим изделиям и так далее, вплоть до требований по обеспечению сохранения государственной и военной тайны при выполнении работ по созданию системы безопасности и требования по обеспечению режима секретности.
Если вдумчиво подойти к данному разделу, то, скорее всего, большую часть требований вы сочтете излишними, особенно если исполнитель отличается банальным здравым смыслом, а ваш объект не является предметом государственной тайны или объектом повышенной опасности (химические и прочие производства, электростанции, объекты министерства обороны и т.п.). Тем не менее, требования по климатическим условиям системы, по эргономике, надежности и расширяемости (возможности модернизации), так или иначе, советуем в ТЗ изложить.
Иначе говоря, самое время для написания «хотелок», касающихся условий и режима работы системы (круглосуточно, при любых погодных условиях от -35 до +40, или же внутри помещения, только в дневное/ночное время, не более 8 часов в сутки, при стабильном освещении и температуре +22°С), возможности и необходимости расширения системы (будет ли в дальнейшем наращиваться система), удобства работы с системой (в большей степени это может коснуться центрального оборудования и мест его размещения), обеспечения непрерывности работы системы (это требование определяет параметры системы бесперебойного питания необходимой мощности) и т.п.
При этом, будьте готовы к тому, что от ваших требования будет напрямую зависеть:
- цена вопроса;
- требования к предоставляемым помещениям и персоналу.
Поясняю: если вы требуете обеспечение электропитания в течение 24 часов при отсутствии основного источника, т.е. работу на аккумуляторах, то готовьте помещение, квадратов этак 40-60, для размещения стеллажей с аккумуляторами, а также не забудьте, что аккумуляторы тепла не любят, а любят кондиционеры, так что разоритесь еще на установку кондиционирования воздуха. Опять же: обслуживать это электрохозяйство кто-то должен, так что предусмотрите в штатном расписании должность техника-электрика. Примерно такой ход рассуждения справедлив для всех «хотелок». С другой стороны, упустив в ТЗ какую-нибудь, даже маловажную деталь, вы можете здорово попасть, и хорошо, если это выяснится в процессе, например, монтажа — это повлечет относительно небольшие затраты на «дозакупку» чего-либо, а вот если система уже будет сдана, и окажется, что половина оборудования не соответствует реально существующим условиям, вот это будет уже сложновато исправить.
Требования к отдельным подсистемам.
В данном разделе рассматриваются требования к составляющим системы, к ее подразделам-подсистемам. В общем и целом, данные раздел включает те аспекты, которые слишком «мелковаты» для раздела «Технический объем работ» и слишком частные для «Требований к системе в целом». Здесь можно рассмотреть как раз такие подробности, как, например, цветные или ч/б видеокамеры вы хотите использовать (хотя пример не слишком удачен, наличие ч/б или цветного изображения зависит в большей степени от целей системы, чем от хотения заказчика), наличие у видеокамер трансфокаторов с управлением, цвет считывателей СКУД, наличие извещателей ОПС с радиоканалом, чтобы не тянуть кабель. Тут же можно уточнить места и правила прокладки кабельных трасс (особенно это имеет значение в офисных помещениях с дорогим ремонтом) и т.п. В этом же разделе оговариваются и такие важные части системы, как система сетевого компьютерного управления (ССКУ, она же специализированная локальная компьютерная сеть) и требования к ПО. Чаще всего, в качестве обязательных требований возникают такие, как: наличие базы данных сотрудников (редактор пропусков), учет рабочего времени сотрудников, наличие подсистемы «Столовая» для фиксации количества обедающих, возможность интеграции с 1С для выдачи табелей и т.п., всяческие подробности по ведению архива данных, и даже интерфейс основного окна дежурного, для, скажем, оператора на проходной, и администратора системы. В качестве необязательных — требования к интерфейсу, требования по защите ПО и т.п. Подробнее о ПО мы поговорим отдельно, в следующей статье.
В качестве прочих требований могут выступать любые, являющиеся важными и критичными с точки зрения заказчика, который, как известно, всегда прав.
Как правило, грамотный исполнитель только порадуется наличию подробного и толкового ТЗ, особенно, если за каждый из пунктов ТЗ заказчик сможет «ответить» — почему именно так он считает нужным сделать. В свою очередь, заказчику стоит прислушаться и к советам исполнителя, если советы выглядят компетентными и логичными. Частенько, это позволяет сэкономить и время, и деньги, и добиться результата — создания системы, отвечающей всем требованиям заказчика с минимальными затратами.
Подходя к написанию ТЗ на систему, ответьте себе на такие вопросы, как:
- Для чего вам система (что и от кого защищаем)?
- Какие вопросы решит создание системы? (т.е. каков ожидаемый эффект?)
- Какие части объекта вы хотите защитить? (выделяем локальные зоны)
- Как хотим защищать? (Хочу видеть, знать, иметь систему оповещения и т.п.)
Примечание: на самом деле, в этот вопрос включается львиная доля конкретных требований как к системе в целом так и к ее составляющим.
- В каких помещениях будет располагаться центральное оборудование и сопутствующие устройства? (серверная, аппаратная, операторская, диспетчерская и т.п.)
- Каким персоналом вы собираетесь обслуживать систему (операторы, диспетчеры, техники и пр.)
И, наконец,
- Сколько денег вы готовы потратить?
Источник — компания “АКСЕС”
Сразу оговоримся — эта статья не предназначена для людей, свободно оперирующих понятиями ЕСКД и ГОСТами 34.ХХХХ и 19.ХХХХ серий. Статья ориентирована на людей, не умеющих писать ТЗ (Техническое Задание).
Для чего нужно ТЗ.
Рассмотрим примитивную ситуацию: вы купили дом и собаку для охраны… собаке надо где-то жить, а значит, нужна конура. Казалось бы, все просто. Пришел профессиональный строитель собачьих домиков дядя Вася, за пару дней соорудил будку с цепью и приглашает вас принять работу. Вы приходите, и что вы обнаруживаете? Будка построена «летняя», а собака должна жить круглый год, вход в конуру расположен со стороны двора, а вам бы хотелось, чтобы собака смотрела на ворота, цепь не дотягивается до сарайчика, а там хранятся ваши ценные садовые инструменты и техника. В общем, деньги потрачены зря, вы недовольны, дядя Вася не понимает, в чем он виноват, так как сделал все по его разумению отлично. А проблема была в отсутствии Технического Задания…
Системы безопасности, о которых пойдет речь, во много раз сложнее конуры для собаки, и, тем не менее, процессы написания ТЗ будет похожи. В ТЗ должны быть однозначно определены такие моменты, как
— цель создания системы (назначение системы);
— технический объем работ;
— требования к системе в целом;
— требования к отдельным подсистемам;
— прочие требования.
Данное разбиение носит условный, хотя и проверенный временем порядок.
Рассмотрим подробнее каждый из разделов ТЗ.
Цель создания системы.
В данном разделе обозначается, собственно, основная причина для создания системы, например: предотвращение воровства имущества, в том числе, инструментов и урожая, находящегося на территории частной собственности заказчика. Или: повышение защищенности объекта путем создания интегрированной технической системы безопасности. Цель может быть изложена и более развернуто, однако, чаще всего, для этого используются последующие разделы ТЗ.
Далее, имеет смысл описать, собственно, ваш объект и те участки объекта, которые вы хотите защищать (так называемые локальные зоны).
К примеру: Объект представляет собой участок в городской застройке, огороженный по периметру бетонным забором с воротами и калиткой. На участке расположен одноэтажный жилой дом и хозяйственные постройки.
Или: Объект состоит из следующих зданий и сооружений: офисное здание №1, 3 этажа, кирпичная постройка, имеет центральный вход и пожарный эвакуационный выход. Соединено с офисным зданием №2 закрытой галереей на уровне 2-го этажа. Офисное здание №2 8 этажей, имеет 4 пожарных эвакуационных выхода. Пятый и шестой этажи — ВИП, доступ ограничен.
Как показывает опыт, любой объект может быть описан таким образом, чтобы в дальнейшем не возникало разногласий по поводу обозначения того или иного строения или значимой его части (цеха, отдела, этажа, помещения и т.п.). Объект стоит разделять на локальные зоны охраны, особенно, если они будут оснащаться различными системами, или должны иметь различные степени защиты.
Например, при описании объекта «банк» имеет смысл заострять внимание на таких помещениях, как «касса», «хранилище», «операционный зал», «банкомат» и т.п. так как подобные помещения будут существенно отличаться по степени защиты от всех остальных. При наличии на объекте периметра большого размера, имеет смысл выделить в отдельные зоны все имеющиеся ворота и калитки, так как их оснащение будет существенно отличаться от оснащения забора (разумеется в случае, если вы ими пользуетесь), а также разбить периметр на рубежи, если предусмотрены различные способы охраны различных участков. А вот разделять на отдельные зоны 6 этажей офисного здания, оснащаемых по одному принципу, смысла не имеет.
В этом же разделе целесообразно указать, из каких конкретно подсистем будет состоять ваша система безопасности.
Технический объем работ.
В данном разделе описывается, что же конкретно нужно сделать в рамках создания системы. А именно: примерно описать, какую локальную зону (обозначенную в предыдущем разделе) какими средствами каких подсистем надо защитить. При этом не обязательно (и даже нежелательно) загромождать этот раздел сложными техническими описаниями устанавливаемых устройств или указывать количество видеокамер на периметре с точностью до единицы, или, тем паче, обозначать фокусное расстояние объектива, или высоту размещения считывателя. В ТЗ вообще, по возможности, не должны фигурировать конкретные марки оборудования и жесткие параметры (кроме случаев, вызванных необходимостью соблюдения, например, климатических требований, но об этом чуть позже). В данном разделе максимально описываются ваши «хотелки» — то самое, на основании чего грамотный исполнитель и составит вам спецификацию и/или изготовит проектную документацию.
В качестве примера: допустимо писать, что «установленные на периметре видеокамеры должны обеспечивать распознавание лица нарушителя, пересекающего забор на любом участке периметра» Или: «размещение телевизионных камер должно обеспечивать сплошную полосу наблюдения и исключать «мертвые» зоны на этой полосе». Или: «на въезде/входе на территории локальных зон оборудовать проходные шлюзового типа для прохода персонала. Проходные должна быть оборудованы элементами СКУД (магнитоконтактными датчиками положения дверей, считывателями магнитных карт, электромагнитными замками) и элементами СВН, позволяющими однозначно идентифицировать проходящий персонал». И такие формулировки будет правильнее, чем, «установить на всей протяженности периметра 29 видеокамер с фокусным расстоянием 6мм» или «установить поясной турникет марки ХХХ, с двумя считывателями YYY, на высоте 1,2 м, а также две видеокамеры на вход и на выход на расстоянии 6 м от прохода, на высоте 3 м». Вы можете, конечно, выполнить львиную долю работы исполнителя, продумав за него, какое оборудование и в каких конкретно конфигурациях вы собираетесь использовать, но при этом:
1) будьте готовы, что ваши ошибки по подбору оборудования будут исправляться за ваш счет или не будут исправляться вовсе;
2) вполне возможно, что, используя подобранное вами оборудование, целей создания системы вы так и не достигнете.
Задача заказчика определить «что», а задача исполнителя предложить «как».
Требования к системе в целом.
Если обратиться к нормативной документации, то в данном разделе вы найдете массу требований, таких как:
— требования к безопасности эксплуатации технических средств;
— требования по эксплуатации, удобству технического обслуживания, ремонта и хранения;
— требования по транспортабельности;
— требования к возможности модернизации;
— требования по эргономике к рабочим местам;
— требования к надежности;
— требования по стандартизации и унификации;
— требования к сырью, материалам и комплектующим изделиям и так далее, вплоть до требований по обеспечению сохранения государственной и военной тайны при выполнении работ по созданию системы безопасности и требования по обеспечению режима секретности.
Если вдумчиво подойти к данному разделу, то, скорее всего, большую часть требований вы сочтете излишними, особенно если исполнитель отличается банальным здравым смыслом, а ваш объект не является предметом государственной тайны или объектом повышенной опасности (химические и прочие производства, электростанции, объекты министерства обороны и т.п.). Тем не менее, требования по климатическим условиям системы, по эргономике, надежности и расширяемости (возможности модернизации), так или иначе, советуем в ТЗ изложить.
Иначе говоря, самое время для написания «хотелок», касающихся условий и режима работы системы (круглосуточно, при любых погодных условиях от -35 до +40, или же внутри помещения, только в дневное/ночное время, не более 8 часов в сутки, при стабильном освещении и температуре +22°С), возможности и необходимости расширения системы (будет ли в дальнейшем наращиваться система), удобства работы с системой (в большей степени это может коснуться центрального оборудования и мест его размещения), обеспечения непрерывности работы системы (это требование определяет параметры системы бесперебойного питания необходимой мощности) и т.п.
При этом, будьте готовы к тому, что от ваших требования будет напрямую зависеть:
1) цена вопроса;
2) требования к предоставляемым помещениям и персоналу.
Поясняю: если вы требуете обеспечение электропитания в течение 24 часов при отсутствии основного источника, т.е. работу на аккумуляторах, то готовьте помещение, квадратов этак 40-60, для размещения стеллажей с аккумуляторами, а также не забудьте, что аккумуляторы тепла не любят, а любят кондиционеры, так что разоритесь еще на установку кондиционирования воздуха. Опять же: обслуживать это электрохозяйство кто-то должен, так что предусмотрите в штатном расписании должность техника-электрика. Примерно такой ход рассуждения справедлив для всех «хотелок». С другой стороны, упустив в ТЗ какую-нибудь, даже маловажную деталь, вы можете здорово попасть, и хорошо, если это выяснится в процессе, например, монтажа — это повлечет относительно небольшие затраты на «дозакупку» чего-либо, а вот если система уже будет сдана, и окажется, что половина оборудования не соответствует реально существующим условиям, вот это будет уже сложновато исправить.
Требования к отдельным подсистемам.
В данном разделе рассматриваются требования к составляющим системы, к ее подразделам-подсистемам. В общем и целом, данные раздел включает те аспекты, которые слишком «мелковаты» для раздела «Технический объем работ» и слишком частные для «Требований к системе в целом». Здесь можно рассмотреть как раз такие подробности, как, например, цветные или ч/б видеокамеры вы хотите использовать (хотя пример не слишком удачен, наличие ч/б или цветного изображения зависит в большей степени от целей системы, чем от хотения заказчика), наличие у видеокамер трансфокаторов с управлением, цвет считывателей СКУД, наличие извещателей ОПС с радиоканалом, чтобы не тянуть кабель. Тут же можно уточнить места и правила прокладки кабельных трасс (особенно это имеет значение в офисных помещениях с дорогим ремонтом) и т.п. В этом же разделе оговариваются и такие важные части системы, как система сетевого компьютерного управления (ССКУ, она же специализированная локальная компьютерная сеть) и требования к ПО. Чаще всего, в качестве обязательных требований возникают такие, как: наличие базы данных сотрудников (редактор пропусков), учет рабочего времени сотрудников, наличие подсистемы «Столовая» для фиксации количества обедающих, возможность интеграции с 1С для выдачи табелей и т.п., всяческие подробности по ведению архива данных, и даже интерфейс основного окна дежурного, для, скажем, оператора на проходной, и администратора системы. В качестве необязательных — требования к интерфейсу, требования по защите ПО и т.п. Подробнее о ПО мы поговорим отдельно, в следующей статье.
В качестве прочих требований могут выступать любые, являющиеся важными и критичными с точки зрения заказчика, который, как известно, всегда прав.
Как правило, грамотный исполнитель только порадуется наличию подробного и толкового ТЗ, особенно, если за каждый из пунктов ТЗ заказчик сможет «ответить» — почему именно так он считает нужным сделать. В свою очередь, заказчику стоит прислушаться и к советам исполнителя, если советы выглядят компетентными и логичными. Частенько, это позволяет сэкономить и время, и деньги, и добиться результата — создания системы, отвечающей всем требованиям заказчика с минимальными затратами.
Подходя к написанию ТЗ на систему, ответьте себе на такие вопросы, как:
- Для чего вам система (что и от кого защищаем)?
- Какие вопросы решит создание системы? (т.е. каков ожидаемый эффект?)
- Какие части объекта вы хотите защитить? (выделяем локальные зоны)
- Как хотим защищать? (Хочу видеть, знать, иметь систему оповещения и т.п.)
Примечание: на самом деле, в этот вопрос включается львиная доля конкретных требований как к системе в целом так и к ее составляющим.
- В каких помещениях будет располагаться центральное оборудование и сопутствующие устройства? (серверная, аппаратная, операторская, диспетчерская и т.п.)
- Каким персоналом вы собираетесь обслуживать систему (операторы, диспетчеры, техники и пр.)
И, наконец,
- Сколько денег вы готовы потратить?
Источник — компания “АКСЕС”
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ
НАЦИОНАЛЬНЫЙ
СТАНДАРТ
РОССИЙСКОЙ
ФЕДЕРАЦИИ
Производственные услуги
СИСТЕМЫ БЕЗОПАСНОСТИ ТЕХНИЧЕСКИЕ
Задание на проектирование
Общие требования
Издание официальное
Москва
Стандартинформ
2017
Предисловие
1 РАЗРАБОТАН Обществом с ограниченной ответственностью «СТАЛТ ЛТД» (ООО «СТАЛТ ЛТД»), Калашниковым Сергеем Александровичем и Ассоциацией «Национальный союз организаций в области обеспечения пожарной безопасности» («НСОПБ»)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 001 «Производственные услуги»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 26 октября 2017 г. № 1522-ст
4 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
© Стандартинформ, 2017
Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии
ГОСТ P 57839—2017
7.1.2 Содержание подраздела «Сведения о защищаемом объекте»
Данный подраздел целесообразно разделить на следующие пункты:
— назначение и краткое описание объекта;
— идентификационные признаки объекта.
7.1.2.1 В пункте «Назначение и краткое описание объекта»:
а) указывают назначение объекта защиты;
б) приводят характеристики зданий, сооружений, территорий, площадок, периметров, акваторий и других составных частей объекта со ссылками на приложенные к заданию чертежи (генплан, строительные чертежи, поэтажные планы и др.);
в) приводят краткое описание функционирования объекта, производственных и технологических процессов, оборудования и материалов, состава и численности персонала и посетителей, транспортных потоков, данные о наличии (отсутствии) на объекте нескольких разных организаций и арендаторов и другие необходимые сведения.
7.1.2.2 В пункте «Идентификационные признаки объекта» указывают следующие данные:
а) уровень ответственности объекта согласно Федеральному закону № 384-ФЗ [3] и принадлежность объекта к перечню согласно статьи 48.1 ГрК РФ [2];
Примечание — Декларация промышленной безопасности объекта, при ее наличии, должна быть приложена к заданию на проектирование.
б) наличие на объекте опасных производственных процессов и присвоенный класс опасности согласно Федеральному закону от 21 июля 1997 г. № 116-ФЗ [8];
в) перечень зданий, сооружений, помещений, наружных установок и электрооборудования, подлежащих защите проектируемой технической системой безопасности, с указанием категорий по пожарной и взрывопожарной опасности согласно Федеральному закону № 123-ФЗ [5];
Примечание — Декларация пожарной безопасности объекта, при ее наличии, должна быть приложена к заданию на проектирование.
г) наличие на объекте помещений с постоянным пребыванием людей и помещений с массовым пребыванием людей;
д) класс объекта по СП 132.13330.2011 в зависимости от возможного ущерба в случае реализации террористических угроз.
7.2 Содержание раздела «Назначение системы и общие требования к проектированию»
В данном разделе указывают:
а) назначение и цели создания системы;
б) перечень составных частей объекта защиты (зданий, сооружений, территорий, периметров), на которых должны быть установлены элементы проектируемой системы и/или на которые распространяется сфера деятельности системы;
в) стадии проектирования (проектная документация и/или рабочая документация), плановые сроки начала и окончания проектирования каждой стадии (или продолжительность каждой стадии) и общие сроки проектирования;
г) сведения о связи разрабатываемой в соответствии с настоящим заданием проектной (рабочей) документации с более общей документацией:
— разрабатываемая документация имеет самостоятельный характер;
— разрабатываемая документация является частью документации на комплексную (интегрированную или иную) систему безопасности;
— разрабатываемая документация является частью документации на объект в целом;
д) перечень и очередность вводимых в действие составных частей объекта и соответствующих частей создаваемой системы (пусковых комплексов) и временной регламент реализации каждой очереди (при выполнении работ в две или более очереди);
е) требования конфиденциальности.
7.3 Содержание раздела «Исходные данные для проектирования»
7.3.1 В данный раздел включают перечень прилагаемых к заданию документов, необходимых для проектирования.
В случае отсутствия отдельных документов из числа необходимых и включенных в данный перечень должен быть указан способ их получения.
7
7.3.2 Исходные данные в общем случае включают следующие документы:
а) отчеты по результатам инженерных изысканий на объекте;
б) проектную и/или рабочую документацию на объект либо часть такой документации, необходимой для проектирования системы;
Примечание — Типовой перечень архитектурно-строительных чертежей, прилагаемых к заданию, приведен в приложении В.
в) чертежи конструктивные технологического оборудования;
г) технические условия на подключение системы к сетям инженерно-технического обеспечения;
Примечание — При отсутствии технических условий на подключение системы к сетям инженерно-технического обеспечения проектировщик разрабатывает и выдает заказчику задания на получение таких технических условий.
д) отчеты о законченных научно-исследовательских работах;
е) информационные материалы на отечественные и зарубежные системы-аналоги.
7.3.3 Данный раздел задания при необходимости и в соответствии с Федеральным законом № 384-ФЗ ([3], часть 3 статьи 15) может предусматривать требования научного сопровождения процесса проектирования.
7.4 Содержание раздела «Нормативные требования к проектированию»
7.4.1 Содержание подраздела «Требования к выбору способа обоснования, подтверждения и оценки соответствия проектных решений»
В данном подразделе в дополнение к ссылкам на требования технических регламентов заказчик указывает конкретный способ обоснования, подтверждения и оценки соответствия проектных решений, который должен быть применен при проектировании (либо выполнение требований документов в области стандартизации, на основании применения которых подтверждается выполнение требований технических регламентов, либо конкретный выбор одного или нескольких способов из указанных в пунктах 1—4 части 6 статьи 15 Федерального закона № 384-ФЗ [3]).
Допускается указывать, что выбор способа обоснования, подтверждения и оценки соответствия проектных решений должен быть определен проектировщиком и дополнительно согласован с заказчиком.
В случае если заказчиком требования к выбору или согласованию способа обоснования, подтверждения и оценки соответствия проектных решений не установлены, проектировщик определяет этот выбор самостоятельно.
В случае если для подготовки проектной документации требуется отступление от требований нормативных документов или такие требования не установлены, к заданию на проектирование должны прилагаться СТУ, разработанные и согласованные в установленном порядке.
7.4.2 Содержание подраздела «Перечень нормативных документов»
В случае если заказчиком определен выбор способа обоснования проектных решений путем ссылок на документы по стандартизации, в данном подразделе должен быть приведен список нормативных документов, действие которых распространяется на создаваемую систему.
Кроме документов, на основании применения которых подтверждается выполнение требований технических регламентов, в указанный перечень могут входить и иные нормативные документы или отдельные разделы (части) этих документов, не противоречащие положениям законодательства Российской Федерации.
При необходимости заказчик может включать в указанный перечень соответствующие зарубежные и международные стандарты и своды правил или их отдельные разделы.
Положения всех документов или их отдельных разделов (частей), указанных в перечне нормативных документов задания, являются обязательными для применения при проектировании.
Положения документов по стандартизации, имеющих отношение к проектируемой системе безопасности и включенных в перечень документов по стандартизации, на основании обязательного применения которых подтверждается выполнение требований принятых технических регламентов (по состоянию на момент передачи проектной документации на экспертизу), подлежат применению независимо от их включения в перечень нормативных документов данного подраздела задания.
ГОСТ P 57839—2017
7.5 Содержание раздела «Технические требования к проектируемой системе»
7.5.1 Содержание подраздела «Требования к функциям, параметрам и характеристикам системы»
7.5.1.1 В данном подразделе устанавливают общие требования к функциям, режимам работы, основным техническим параметрам и характеристикам системы, обеспечивающим выполнение возложенных на систему задач и определяющим качество функционирования системы и безопасность объекта.
7.5.1.2 Требования к проектным параметрам и характеристикам системы должны быть установлены таким образом, чтобы в процессе строительства и эксплуатации система была безопасной для граждан, имущества и среды согласно требованиям Федерального закона № 384-ФЗ ([3], часть 5 статьи 15).
7.5.1.3 В задании не допускается приводить требования к системе, содержащиеся в технических регламентах и включенные в перечни документов в области стандартизации, на основании обязательного применения которых обеспечивается выполнение требований принятых технических регламентов, а также содержащиеся в документах добровольного применения, если эти документы включены в подраздел «Перечень нормативных документов» задания согласно 7.4.2 настоящего стандарта.
7.5.1.4 В задании должны быть указаны требования по доступности системы для обслуживающего персонала по проверке фактических значений параметров, характеристик и качества функционирования системы согласно Федеральному закону № 384-ФЗ ([3], часть 8 статьи 15).
Требования по доступности системы для персонала должны быть согласованы с требованиями по защите информации от НСД согласно 7.5.12.2 настоящего стандарта и не противоречить им.
Примечание — Требования по доступности системы только для сервисных организаций могут быть заданы, например, через специальную процедуру, с системой паролей, пломбирования и регистрацией действий специалистов в энергонезависимой нестираемой памяти («черном ящике»),
7.5.2 Содержание подраздела «Требования к архитектуре и топологии системы»
7.5.2.1 В данном подразделе приводят:
а) общие требования к архитектуре и топологии создаваемой системы в целом;
б) требования к масштабируемости;
в) требования к каналам связи и интерфейсам передачи данных;
г) требования по объединению в единую систему приборов и оборудования территориально удаленных объектов;
д) требования по дистанционному взаимодействию аппаратных средств (приборов) и рабочих станций на основе ПК с центральным оборудованием (сервером) через локальную и/или глобальную сеть, радиоканалы и другие каналы связи.
7.5.2.2 Выполнение указанных требований должно обеспечивать необходимое быстродействие, надежность, устойчивость, поэтапную наращиваемость (при необходимости), универсальность по отдельным элементам (линиям связи, источникам электропитания и пр.), энергетическую и экономическую эффективность и другие параметры проектируемой системы безопасности.
7.5.3 Содержание подраздела «Требования к системе по сопряжению с другими системами и оборудованием»
В данном подразделе приводят:
а) требования по взаимодействию создаваемой системы безопасности с другими техническими системами безопасности объекта, а также при необходимости с другими техническими средствами на объекте;
б) требования к параметрам и характеристикам взаимосвязей системы с другими системами, включая требования по быстродействию, в том числе указания об аппаратных и/или программных способах обмена информацией, требования по применяемым стандартным или иным интерфейсам передачи данных.
7.5.4 Содержание подраздела «Требования к применяемому оборудованию»
Данный подраздел разрабатывают в случае, если к применяемому в составе системы оборудованию, приборам, устройствам и техническим средствам необходимо установить требования, дополнительные по отношению к предусмотренным соответствующими техническими регламентами или указанными в них документами по стандартизации обязательного применения, а также в документах добровольного применения, если эти документы включены в подраздел «Перечень нормативных документов» задания согласно 7.4.2 настоящего стандарта.
9
Если применяемое оборудование в соответствии с действующим законодательством подлежит обязательному подтверждению соответствия (сертификации), то указанные в задании требования к этому оборудованию должны соответствовать и не противоречить положениям соответствующих документов по стандартизации.
В задании допускается указывать рекомендованное к применению в проекте оборудование, приборы, устройства и технические средства, например для унификации или интеграции оборудования, применяемого при проектировании с уже имеющимся на объекте оборудованием аналогичного функционального назначения или с оборудованием, обоснованно применяемым в других, уже разработанных проектах, а также предусмотренное, например, положениями стандарта организации заказчика. При этом должна быть указана причина, по которой предлагается применить данное оборудование.
Для объектов, относящихся к перечню статьи 48.1 ГрК РФ [2], или если функциональные или технические параметры систем для данного объекта проектирования установлены принятыми техническими регламентами или иными обязательными для применения документами ФОИВ, не допускается включать в задание требования о применении конкретных видов оборудования, за исключением тех случаев, когда это предусмотрено соответствующим стандартом организации-заказчика. Указанный стандарт организации (или его часть, относящаяся к проектируемой системе) должен пройти экспертизу и получить положительное заключение профильного технического комитета по стандартизации, а также должен быть включен в подраздел «Перечень нормативных документов» задания согласно 7.4.2 настоящего стандарта.
В случае если при согласовании задания или в процессе проектирования проектировщиком выявлено несоответствие параметров и характеристик оборудования, рекомендованного заказчиком, требованиям нормативных документов применительно к конкретному объекту или с применением этого оборудования не могут быть выполнены иные предъявленные заданием технические требования, то проектировщик в соответствии с положениями 5.12 настоящего стандарта должен направить заказчику мотивированное обоснование невозможности применения указанного оборудования.
Решение о выборе конкретного оборудования при проектировании системы для достижения ее параметров и характеристик, указанных в задании, в технических регламентах и других документах обязательного применения, а также в документах, включенных в подраздел «Перечень нормативных документов» задания согласно 7.4.2 настоящего стандарта, принимает проектировщик и несет полную ответственность за соответствие выбранного оборудования требованиям, предъявляемым к системе.
7.5.5 Содержание подраздела «Требования к применяемому оборудованию ВТ и программному обеспечению»
В данном подразделе указывают назначение средств ВТ: для выполнения (полностью или частично) основных функций проектируемой системы; для дополнительного применения в качестве АРМ операторов с наглядным отображением состояния системы; для периодического применения в качестве средств контроля, наладки, диагностирования и программирования.
В случае если средства ВТ применяются для выполнения (полностью или частично) основных функций проектируемой системы, то на них распространяются требования 7.5.4 настоящего стандарта, а также положения ГОСТ Р 53325-2012, статья 7.2.5.
Дополнительно могут быть указаны следующие требования:
а) требования к количеству рабочих станций и других АРМ и распределению полномочий между
ними;
б) требования об ограничениях или предпочтениях в применении покупных программных средств;
в) требования о сертификации применяемого программного обеспечения;
г) требования к отображению на экранах АРМ данных о работе системы и по управляющим полномочиям операторов;
д) требования к протоколированию информации (отображения и регистрации действий операторов).
7.5.6 Содержание подраздела «Конструктивные и эргономические требования»
7.5.6.1 В данном подразделе приводят следующие конструктивные требования:
а) требования к массогабаритным характеристикам компонентов системы;
б) требования по удобству крепления приборов и устройств системы при монтаже и возможности замены приборов без замены подводимых кабельных изделий;
в) требования по защите приборов и устройств от несанкционированного доступа посторонних лиц.
7.5.6.2 В данном подразделе приводят следующие эргономические требования:
а) перечень нормативных и иных документов по эргономике и технической эстетике, которым должна соответствовать создаваемая система;
10
ГОСТ P 57839—2017
б) требования обеспечения необходимого качества взаимодействия человека с системой и комфортности условий для персонала и пользователей;
в) перечень показателей по эргономике и технической эстетике или требование разработать перечень таких показателей в процессе проектирования и требование определить значения этих показателей.
7.5.7 Содержание подраздела «Требования по размещению оборудования и прокладке линий коммуникаций»
В данном подразделе приводят:
а) предварительный перечень помещений для размещения станций пожаротушения, пожарных постов, постов охраны, насосных, операторских, диспетчерских, аппаратных, серверных и других выделенных помещений;
б) предварительные требования по размещению периферийного оборудования на этажах, в коридорах, тоннелях, на площадках и периметрах;
в) предварительные требования по размещению элементов, приборов и средств создаваемой системы непосредственно в защищаемых помещениях, на площадках и периметрах;
г) предварительные требования по прокладке коммуникаций, трубопроводов и кабелей вертикальной и горизонтальной составляющих.
7.5.8 Содержание подраздела «Требования к электропитанию»
В данном подразделе приводят:
а) сведения об энергообеспечении объекта, наличии основных и резервных вводов электроснабжения, их параметрах и характеристиках, наличии (отсутствии) автоматического ввода резерва;
б) указания о необходимости разработки, обоснования, включения в проектную документацию и реализации в проектных решениях следующих требований к источникам электроснабжения объекта для функционирования создаваемой системы:
— требования к энергопотреблению и времени непрерывной работы системы в дежурном режиме и в режиме пуска исполнительных устройств;
— требования к резервным источникам электропитания, обеспечивающим работоспособность системы (в случае пропадания основного электропитания) во всех режимах в течение заданного времени;
— требование создания автоматического ввода резерва;
— требование о включении в состав системы источников бесперебойного электропитания на основе аккумуляторных батарей;
— требования к защитному заземлению приборов и устройств и их подключению к заземляющей шине.
7.5.9 Содержание подраздела «Требования электромагнитной совместимости»
В данном подразделе приводят:
а) данные о параметрах электромагнитных полей на объекте в целом и в отдельных помещениях, зонах, на площадках, периметрах и в других составных частях объекта;
б) требования устойчивости приборов и устройств системы к воздействию внешних электромагнитных полей;
в) требования к допустимому уровню электромагнитных помех, создаваемых приборами и устройствами системы.
7.5.10 Содержание подраздела «Требования к защите от внешних воздействий»
В данном подразделе указывают:
а) предварительный перечень приборов и устройств системы, для которых, согласно заданию на проектирование, необходима наружная установка и/или установка в помещениях с особыми условиями эксплуатации по климатическим, механическим и другим внешним воздействиям;
б) условия эксплуатации приборов и устройств по климатическим, механическим и другим внешним воздействиям.
7.5.11 Содержание подраздела «Требования надежности»
В данном подразделе устанавливают:
а) значения показателей надежности для системы в целом и/или ее составных частей;
б) перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности (в том числе потеря электропитания), и значения соответствующих показателей;
в) требования к надежности программного обеспечения.
7.5.12 Содержание подраздела «Требования к сохранности информации и защите информации от НСД»
Данный подраздел целесообразно разделить на следующие пункты:
— требования по сохранности информации;
— требования к защите информации от НСД.
11
7.5.12.1 В пункте «Требования по сохранности информации» устанавливают:
а) перечень аварийных событий и отказов технических средств (в том числе потеря электропитания), при которых должна быть обеспечена сохранность информации в системе;
б) требования к аппаратным средствам, обеспечивающим устойчивость системы при авариях, в том числе требования по резервированию приборов;
в) требования к программным средствам, обеспечивающим сохранность информации при авариях, в том числе требования по дублированию баз данных и резервированию серверов.
7.5.12.2 В пункте «Требования к защите информации от НСД» устанавливают:
а) требования по защите от НСД согласно требованиям Федерального закона от 27 июля 2006 г. № 149-ФЗ ([9], статья 6), а также нормативным и правовым документам, действие которых распространяется на системы данного вида;
б) требования к конструкции приборов и устройств по обеспечению их защиты от НСД;
в) требования к средствам ВТ на основе ПК по защите информации от НСД.
7.5.13 Содержание подраздела «Требования безопасности»
7.5.13.1 В данном подразделе должны быть установлены требования безопасности по защите жизни, здоровья, имущества и среды согласно Федеральному закону № 384-ФЗ ([3], статьи 7—15).
При отсутствии в задании на проектирование этих требований последние устанавливаются на минимально необходимом уровне в соответствии с Федеральным законом № 384-ФЗ ([3], часть 6 статьи 3].
7.5.13.2 В данном подразделе должен быть установлен уровень ответственности системы в соответствии с уровнем ответственности защищаемого объекта (см. 7.1.2.2).
7.5.14 Содержание подраздела «Требования стандартизации и унификации»
В данном подразделе указывают:
а) показатели, устанавливающие требуемую степень использования стандартных методов реализации функций и задач системы;
б) требования включения в состав системы унифицированных приборов и программных средств;
в) требования использования типовых проектных решений;
г) требования использования типовых автоматизированных рабочих мест, компонентов и комплексов.
7.6 Содержание раздела «Требования экономической эффективности»
7.6.1 В данный раздел включают:
а) требования к затратам на закупку и поставку оборудования и материалов;
б) требования к эксплуатационным затратам:
— требования к обоснованию численности и квалификации эксплуатирующего персонала и затратам на его содержание;
— требования к затратам на техническое обслуживание;
— требования к затратам на расход энергетических ресурсов при эксплуатации и требование исключить нерациональный расход этих ресурсов;
— требования к другим эксплуатационным затратам;
в) перечень показателей эффективности или указания о необходимости установления этих показателей в процессе проектирования и требование определения численных значений этих показателей для создаваемой системы.
7.6.2 При включении в задание (полностью или частично) требований согласно 7.6.1 настоящего стандарта заказчиком должна быть предусмотрена выдача проектировщику соответствующих дополнительных исходных данных, необходимых для проведения расчетов, а договор подряда на проектирование должен учитывать эти работы в части сроков выполнения и стоимости работ.
7.7 Содержание раздела «Требования к монтажу и организации строительства»
7.7.1 Содержание подраздела «Сведения об условиях строительства»
В данном подразделе приводят следующие сведения об условиях строительства:
— новое строительство;
— реконструкция существующего объекта (действующего предприятия);
— капитальный ремонт существующего объекта (действующего предприятия);
— очередности (при выделении очередей реализации проекта).
ГОСТ P 57839—2017
Дополнительно в данном разделе указывают требования к осуществлению авторского надзора при реализации разрабатываемого проекта.
7.7.2 Содержание подраздела «Требования к СМР»
В данном подразделе приводят необходимые требования к СМР.
7.7.3 Содержание подраздела «Требования к маркировке»
В данном подразделе приводят:
а) перечень нормативных документов на маркировку;
б) предварительный перечень маркируемых элементов;
в) требование установления содержания, способов выполнения и мест размещения маркировки.
7.7.4 Содержание подраздела «Требования к испытаниям при ПНР и на этапе опытной эксплуатации, комплексного опробования и ввода в эксплуатацию»
В данном подразделе устанавливают:
а) перечень и виды испытаний системы и ее составных частей на этапах ПНР и ввода в эксплуатацию;
б) перечень нормативных документов, распространяющихся на проектируемую систему, согласно которым устанавливают виды испытаний системы и ее составных частей;
в) состав, объем и методы испытаний системы на этапах ПНР и ввода в эксплуатацию;
г) требования к приемке работ на разных этапах;
д) статус комиссии, принимающей работы, для каждого вида испытаний (рабочая, приемочная).
7.8 Содержание раздела «Требования к эксплуатации, обслуживанию и ремонту»
7.8.1 Содержание подраздела «Общие требования по эксплуатации»
Общие требования по эксплуатации устанавливают согласно Федеральному закону № 384-ФЗ ([3], часть 9 статьи 15 и статья 36), ГОСТ Р 27.601 и ГОСТ Р 54101.
7.8.2 Содержание подраздела «Требования к способам технического обслуживания»
Данный подраздел должен содержать требования установить способы технического обслуживания, которые необходимы и достаточны для эксплуатации системы.
7.8.3 Содержание подраздела «Требования к эксплуатационным показателям, определяемым в процессе проектирования»
Данный подраздел должен содержать требования о необходимости разработать и включить в проектную документацию следующие данные:
а) перечень параметров и характеристик системы, контролируемых в процессе технического обслуживания и при проверке работоспособности;
б) сведения о регламентах обслуживания, объеме и периодичности проверок;
в) данные по численности и квалификации обслуживающего персонала и режиму его работы;
г) порядок текущего ремонта системы и хранения запасного имущества к ней;
д) сведения для пользователей и эксплуатационных служб о значениях предельно допустимых эксплуатационных нагрузок на систему;
е) сведения о размещении скрытно устанавливаемых компонентов системы (электрических проводок, трубопроводов и др.).
7.9 Содержание раздела «Требования к выводу из эксплуатации, демонтажу
и утилизации»
Данный раздел должен содержать:
а) требования по выводу системы из эксплуатации;
б) требования по замене системы новой системой, созданной взамен выводимой из эксплуатации (для объектов, эксплуатация которых продолжается);
в) требование обеспечить безопасное хранение демонтированной системы по ГОСТ Р 55838;
г) требования по утилизации.
7.10 Содержание раздела «Требования к патентной чистоте и защите авторских прав»
В данном разделе приводят:
а) требования независимости проектируемой системы и ее компонентов от охраняемых прав третьих лиц;
13
б) перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей;
в) требования по защите авторских прав на создаваемую интеллектуальную собственность.
7.11 Содержание раздела «Требования к сметной документации»
7.11.1 Содержание подраздела «Требования к разделам сметной документации»
7.11.1.1 Данный подраздел должен содержать указание о включении в сметную документацию следующих обязательных разделов:
а) изыскания;
Примечание — Как указано выше (4.9), изыскания должны предшествовать заданию на проектирование. Поэтому изыскания могут быть прописаны в задании на проектирование в том случае, если необходимые изыскания не проводились или были проведены не в полном объеме.
б) разработка проектно-сметной документации;
в) разработка рабочей документации;
г) оборудование и материалы;
д) демонтаж строительных конструкций, оборудования и инженерных сетей (если есть необходимость выполнять такие работы);
е) СМР;
ж) ПНР.
7.11.1.2 Данный подраздел при необходимости может содержать указание о включении в сметную документацию разделов из числа следующих:
а) авторский надзор;
б) дополнительные затраты на поставку материалов и оборудования;
в) лимитированные затраты;
г) командировочные расходы.
7.11.1.3 Данный подраздел, по указанию заказчика, может содержать требование о необходимости учета прочих работ и затрат для включения в сводный сметный расчет.
7.11.1.4 В данном подразделе устанавливают тип предоставляемого расчета и включают указания о необходимости разработки:
— локальных смет;
— калькуляции затрат по форме «Зп»;
— объектной сметы;
— сводного сметного расчета.
Примечание — Локальный сметный расчет может включать одну или несколько статей затрат (работ).
7.11.1.5 В данном подразделе, по требованию заказчика, может быть указана дата предоставления сметных расчетов.
7.11.2 Содержание подраздела «Исходные данные для выполнения сметных расчетов»
В данном подразделе приводят следующие сведения:
а) указания о применении сметно-нормативной базы для определения базисного уровня цен;
б) наименования нормативных, руководящих и иных документов, устанавливающих сметные нормативы, раздельно по каждому из этапов работ;
в) привязанные к местным условиям единичные расценки;
г) ссылку на документ для принятия индексов пересчета базисных цен в текущий уровень цен;
д) исходные данные для определения накладных расходов и сметной прибыли;
е) описания условий производства работ и указания по обоснованному применению коэффициентов удорожания работ;
ж) исходные данные для определения затрат на ПНР с указанием всех необходимых параметров для расчета смет по ПНР и коэффициента, учитывающего характеристику данной системы;
и) исходные данные для определения дополнительных затрат на поставку материалов и оборудования, лимитированных затрат и командировочных расходов (при выполнении соответствующих расчетов);
к) требования по дополнительным статьям затрат в сметах, в том числе по затратам органов гос-надзора на согласование, экспертизу и выдачу заключений.
ГОСТ P 57839—2017
7.11.3 Содержание подраздела «Требования к представлению сметной документации»
В данном подразделе указывают:
а) методики и программное обеспечение, используемые для разработки сметной документации;
б) формат представления сметной документации.
7.12 Содержание раздела «Требования к документации, подлежащей разработке
и передаваемой заказчику по результатам проектирования»
В данном разделе указывают:
а) перечень, наименования и обозначения подлежащих разработке комплектов и видов документов, соответствующих требованиям ГрК РФ ([2], часть 12 статьи 48) и ГОСТ Р 21.1101, а также других нормативных документов, в соответствии с которыми должна разрабатываться проектная и рабочая документация на конкретную систему (указывают наименования нормативных документов);
б) указания о форме предоставления документов: в бумажной форме и/или на электронных носителях, с указанием вида носителей;
в) перечень заданий, выдаваемых от лица проектировщика в адрес заказчика.
Примечания
1 При отсутствии нормативных документов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.
2 Типовой перечень заданий, выдаваемых проектировщиком заказчику, приведен в приложении Г.
8 Правила изложения и оформления задания
8.1 Разделы, подразделы и пункты задания на проектирование должны быть размещены в порядке, установленном в разделах 6 и 7.
8.2 Задание на проектирование оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и граф к ней.
Номера листов (страниц) проставляют, начиная с листа, следующего за титульным листом, в верхней части листа (над текстом посередине) после слов «Задание на проектирование_наименование системы_наименование объекта».
8.3 Значение показателей, норм и требований указывают, как правило, с допускаемыми предельными отклонениями или в виде максимальных и минимальных значений. Если эти показатели, нормы, требования установлены нормативными документами, в задании на проектирование следует давать ссылки на эти документы или их разделы, а также устанавливать дополнительные требования, учитывающие особенности создаваемой системы.
Если конкретные значения показателей, норм, требований не могут быть установлены в процессе разработки задания на проектирование, то в тексте задания следует сделать запись о порядке установления и согласования этих показателей, норм, требований: «Окончательное требование (значение) уточняется в процессе проектирования и согласовывается с разработчиком задания протоколом на стадии…». Настоящий протокол после его согласования прикладывают к заданию, при этом в текст задания изменений не вносят.
8.4 На титульном листе помещают утверждающую подпись заказчика и согласующие подписи разработчика задания и проектировщика, а также подписи согласующих организаций (при их наличии). При необходимости титульный лист оформляют на нескольких страницах.
Подписи разработчиков задания на проектирование и должностных лиц, участвующих в согласовании и рассмотрении проекта задания на проектирование, помещают на последнем листе.
Примечание — Формы титульного и последнего листов задания на проектирование приведены в настоящем стандарте в приложениях А и Б соответственно.
8.5 Титульный лист дополнения к заданию на проектирование оформляют аналогично титульному
листу задания. Вместо наименования «Задание на проектирование» пишут «Дополнение №_к за
данию на проектирование».
На последующих листах дополнения помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения.
При изложении текста дополнения следует указывать номера соответствующих пунктов, подпунктов, таблиц основного задания на проектирование и применять слова «заменить», «дополнить», «исключить», «изложить в новой редакции».
15
ГОСТ P 57839—2017
Приложение А (рекомендуемое)
Форма титульного листа задания на проектирование
Логотип (при наличии).
УТВЕРЖДАЮ Должность, наименование организации-заказчика
Наименование организации — разработчика «Задания на проектирование»
СОГЛАСОВАНО Должность, наименование организации — разработчика задания на проектирование
Наименование объекта Обозначение (шифр) проекта Наименование системы (установки) Задание на проектирование Обозначение (код) документа
На_листах
Действует с «_»_20_г.
СОГЛАСОВАНО Должность, наименование организации-проектировщика
_И.О. Фамилия
«_»_20_г.
СОГЛАСОВАНО Должность, наименование согласующей организации
_И.О. Фамилия
«_»_20 г.
Санкт-Петербург (или иной населенный пункт) 20 г.
16
ГОСТ P 57839—2017
Содержание
1 Область применения…………………………………………………………1
2 Нормативные ссылки…………………………………………………………1
3 Термины, определения и сокращения…………………………………………….2
4 Основные положения………………………………………………………..3
5 Порядок разработки, согласования и утверждения задания на проектирование.
Ответственность за его содержание……………………………………………..4
6 Состав документа «Задание на проектирование технической системы безопасности»…………4
7 Содержание разделов документа «Задание на проектирование технической
системы безопасности»………………………………………………………6
7.1 Содержание раздела «Общие сведения»………………………………………6
7.2 Содержание раздела «Назначение системы и общие требования к проектированию»………7
7.3 Содержание раздела «Исходные данные для проектирования»………………………7
7.4 Содержание раздела «Нормативные требования к проектированию»………………….8
7.5 Содержание раздела «Технические требования к проектируемой системе»……………..9
7.6 Содержание раздела «Требования экономической эффективности»………………….12
7.7 Содержание раздела «Требования к монтажу и организации строительства»……………12
7.8 Содержание раздела «Требования к эксплуатации, обслуживанию и ремонту»………….13
7.9 Содержание раздела «Требования к выводу из эксплуатации, демонтажу и утилизации»…..13
7.10 Содержание раздела «Требования к патентной чистоте и защите авторских прав»………13
7.11 Содержание раздела «Требования к сметной документации»………………………14
7.12 Содержание раздела «Требования к документации, подлежащей разработке
и передаваемой заказчику по результатам проектирования»………………………15
8 Правила изложения и оформления задания……………………………………….15
Приложение А (рекомендуемое) Форма титульного листа задания на проектирование…………16
Приложение Б (рекомендуемое) Форма последнего листа задания на проектирование…………17
Приложение В (рекомендуемое) Типовой перечень архитектурно-строительных чертежей,
необходимых для проектирования технической системы безопасности
и прилагаемых к заданию на проектирование……………………………18
Приложение Г (рекомендуемое) Типовой перечень заданий, разрабатываемых
проектировщиком для передачи заказчику………………………………18
Библиография………………………………………………………………19
III
ГОСТ P 57839—2017
Приложение Б (рекомендуемое)
Форма последнего листа задания на проектирование
Обозначение (код) документа
СОСТАВИЛИ |
|||||||||||||||
|
СОГЛАСОВАНО |
|||||||||||||||
|
17
Введение
Задание на проектирование предусмотрено рядом правовых документов, регламентирующих строительную сферу, и является одним из основополагающих документов при создании, реконструкции или капитальном ремонте технической системы безопасности как при проведении таких работ только в отношении самой системы, так и при проведении аналогичных работ на объекте защиты в целом или его части.
Единого документа уровня национального стандарта, регламентирующего порядок разработки и утверждения, а также содержание задания на проектирование различных технических систем безопасности, до принятия настоящего стандарта не существовало. Ранее разработанные и чаще всего узко специальные разрозненные документы (ГОСТ 34.602, РД 25.952—90 [1 ] и др.) недостаточно полно отражали современную систему правового регулирования строительной сферы и не соответствовали положениям Градостроительного кодекса Российской Федерации (ГрК РФ) от 29 декабря 2004 г. № 190-ФЗ [2], Федерального закона от 30 декабря 2009 г. № 384-ФЗ [3] и Постановления Правительства Российской Федерации от 16 февраля 2008 г. № 87 [4].
Применение настоящего стандарта и выполнение его требований позволит:
— восполнить существующий нормативный пробел;
— установить требования в отношении обязательности разработки задания на проектирование технической системы безопасности;
— нормировать содержание задания на проектирование и порядок его разработки;
— установить единые требования к заданиям на проектирование всего спектра технических систем безопасности по ГОСТ Р 56936.
Настоящий стандарт является очередным документом в «пакете» стандартов, содержащих требования для полного жизненного цикла технических систем безопасности.
IV
ГОСТ Р 57839-2017
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Производственные услуги СИСТЕМЫ БЕЗОПАСНОСТИ ТЕХНИЧЕСКИЕ
Задание на проектирование
Общие требования
Production services. Technical safety systems. Design data and directions. General requirements
Дата введения — 2018—06—01
1 Область применения
Настоящий стандарт устанавливает состав, содержание и оформление, порядок разработки, согласования и утверждения задания на проектирование технических систем безопасности по ГОСТ Р 56936.
Требования настоящего стандарта распространяются на задания на проектирование для вновь создаваемых технических систем безопасности, а также для ранее построенных систем при их реконструкции и капитальном ремонте.
Положения настоящего стандарта должны применяться к заданию на проектирование технических систем безопасности (далее — систем) в тех случаях, когда оснащение объекта проектируемой системой предусмотрено принятыми техническими регламентами или иными документами по стандартизации, применяемыми для подтверждения соответствия требованиям принятых технических регламентов.
Положениями настоящего стандарта допускается руководствоваться при составлении задания на разработку специальных технических условий (СТУ) согласно федеральным законам от 30 декабря 2009 г. № 384-ФЗ ([3], части 4, 8 и 9 статьи 6), от 22 июля 2008 г. № 123-ФЗ ([5], часть 2 статьи 78) и Приказу Минстроя Российской Федерации от 15 апреля 2016 г. № 248/пр [6] в части разработки требований к техническим системам безопасности.
Стандарт не распространяется на системы специальных военных объектов и объектов атомной отрасли, но может быть использован при разработке соответствующей документации для указанных объектов.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие документы:
ГОСТ 2.105 Единая система конструкторской документации. Общие требования к текстовым документам
ГОСТ 2.301 Единая система конструкторской документации. Форматы
Издание официальное
ГОСТ 34.602 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
ГОСТ Р 21.1101 Система проектной документации для строительства. Основные требования к проектной и рабочей документации
ГОСТ Р 27.601 Надежность в технике. Управление надежностью. Техническое обслуживание и его обеспечение
ГОСТ Р 53325-2012 Техника пожарная. Технические средства пожарной автоматики. Общие технические требования и методы испытаний
ГОСТ Р 54101 Средства автоматизации и системы управления. Средства и системы обеспечения безопасности. Техническое обслуживание и текущий ремонт
ГОСТ Р 55838 Ресурсосбережение. Обращение с отходами. Требования к безопасному хранению списанных изделий перед утилизацией
ГОСТ Р 56936-2016 Производственные услуги. Системы безопасности технические. Этапы жизненного цикла систем. Общие требования
ГОСТ Р 57369 Производственные услуги. Термины и определения
СП 132.13330.2011 Обеспечение антитеррористической защищенности зданий и сооружений. Общие требования проектирования
Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины, определения и сокращения
3.1 Термины
В настоящем стандарте применены термины по ГОСТ Р 57369, а также следующие термины с соответствующими определениями:
3.1.1
задание на проектирование (технической системы безопасности): Обязательный для проведения проектирования системы документ, содержащий перечень требований к системе, условий ее функционирования, целей и задач, решаемых системой, и определяющий порядок работ по проектированию, инсталляции на объекте и последующей эксплуатации системы.
[ГОСТ Р 56936-2016, статья 3.2.7]
3.1.2 заказчик: Застройщик или технический заказчик согласно ГрК РФ ([2], части 16, 22 статьи 1), который заключает договор о подготовке проектной документации, разрабатывает и утверждает задание на проектирование, предоставляет лицу, осуществляющему подготовку проектной документации, материалы и документы, необходимые для подготовки проектной документации.
3.1.3 разработчик (задания на проектирование): Заказчик или привлекаемое им по договору юридическое или физическое, действующее на профессиональной основе, лицо, которое разрабатывает задание на проектирование и несет ответственность за соответствие его содержания требованиям технических регламентов согласно ГрК РФ ([2], части 4, 5 статьи 48).
3.1.4 проектировщик: Привлекаемое заказчиком и действующее на профессиональной основе юридическое или физическое лицо, которое в соответствии с заданием на проектирование осуществляет разработку проектной документации и несет ответственность за ее соответствие требованиям действующих нормативных документов, а также в предусмотренных законом случаях обладает допуском к соответствующим проектным работам согласно требованиям ГрК РФ ([2], часть 4 статьи 48).
ГОСТ P 57839—2017
3.1.5_
проектная документация (технической системы безопасности): Документация, соответствующая требованиям, установленным правовыми документами, содержащая материалы в текстовой форме, в виде расчетов и в виде чертежей и определяющая функционально-технологические, инженерно-технические, строительные и конструктивные решения для построения системы и ее последующей эксплуатации.
[ГОСТ Р 56936-2016, статья 3.2.9]
3.2 Сокращения
В настоящем стандарте применены следующие сокращения:
АРМ — автоматизированное рабочее место;
ВТ — вычислительная техника;
ГК РФ — Гражданский кодекс Российской Федерации;
ГрК РФ — Градостроительный кодекс Российской Федерации;
НСД — несанкционированный доступ;
ПК — персональный компьютер;
ПНР — пусконаладочные работы;
СМР — строительно-монтажные работы;
СРО — саморегулируемая организация;
СТУ — специальные технические условия;
ТЭО — технико-экономическое обоснование;
ФОИВ — федеральный орган (федеральные органы) исполнительной власти.
4 Основные положения
4.1 Задание на проектирование системы является обязательным документом, необходимым для последующей разработки проектной документации системы согласно требованиям ГрК РФ ([2], часть 11 статьи 48).
4.2 Задание на проектирование системы может быть самостоятельным документом либо быть частью задания на проектирование комплексной или интегрированной систем безопасности или частью задания на проектирование объекта в целом.
4.3 Задание на проектирование является основным документом заказчика, определяющим требования и порядок создания (строительства, реконструкции или капитального ремонта; далее — создания) системы, а также требования к составу, содержанию и порядку разработки проектной и/или рабочей документации.
4.4 Дополнительно могут быть разработаны задания на проектирование групп взаимосвязанных (объединенных по функциональному признаку) систем и технические задания на разработку программного обеспечения для них.
4.5 Включаемые в задание на проектирование требования должны соответствовать современному уровню развития науки, техники и технологий и стимулировать к применению наиболее эффективных в техническом и экономическом отношении решений.
4.6 Состав и требования к содержанию разделов проектной документации, предусмотренные заданием на проектирование, не должны противоречить составу и требованиям к содержанию разделов проектной документации, установленным ГрК РФ ([2], часть 13 статьи 48) и Постановлением Правительства РФ № 87 [4].
4.7 Задание на проектирование должно учитывать требования правовых и нормативных документов, действие которых распространяется на создаваемую систему, и не противоречить им.
4.8 Этапу разработки задания на проектирование, как правило, предшествуют инженерные изыскания и/или сбор исходных данных по ГОСТ Р 56936, требуемые для составления задания на проектирование. В необходимых случаях составлению задания должна предшествовать разработка СТУ.
4.9 Задание составляется при проектировании систем для вновь строящихся объектов и при проведении реконструкции или капитального ремонта, в том числе и в отношении самой технической системы безопасности.
3
5 Порядок разработки, согласования и утверждения задания на проектирование. Ответственность за его содержание
5.1 Порядок разработки, согласования и утверждения задания на проектирование определяет заказчик с учетом положений настоящего стандарта.
5.2 Заказчик вправе самостоятельно разработать задание, либо поручить разработку задания проектировщику, либо привлечь к разработке задания третью сторону.
5.3 В случаях, если техническая система безопасности должна быть спроектирована для объекта, относящегося к перечню, указанному в статье 48.1 ГрК РФ [2], или функциональные требования к этой системе регламентированы принятыми техническими регламентами, привлекаемое для разработки задания лицо должно обладать допуском СРО к выполнению соответствующих проектных работ согласно требованиям ГрК РФ ([2], часть 4 статьи 48), включая в необходимых случаях требования Постановления Правительства РФ от 24 марта 2011 г. № 207 [7].
5.4 Лицо, привлекаемое для разработки задания на проектирование, несет ответственность перед заказчиком в соответствии с условиями договора и ГК РФ.
5.5 В соответствии с ГОСТ Р 56936 задание составляется на основании данных, полученных в процессе инженерных изысканий и/или на основании сбора и анализа исходных данных, полученных от заказчика.
При конкурсном отборе лица, привлекаемого для составления задания на проектирование, заказчик предоставляет эти данные всем участникам конкурса или обеспечивает им равные возможности для самостоятельного сбора необходимых данных.
5.6 Утверждает задание и несет ответственность за его содержание и соответствие положениям действующих нормативных документов заказчик, независимо от порядка разработки документа.
5.7 В случаях, предусмотренных законодательством, задание должно быть направлено на согласование (утверждение) в ФОИВ. В этом случае соответствующие ФОИВ несут ответственность в соответствии с законодательством.
5.8 Необходимость согласования задания с другими заинтересованными организациями определяет заказчик.
5.9 Задание может быть подвергнуто метрологической экспертизе, если необходимость в этом определена заказчиком системы или разработчиком задания.
5.10 При конкурсном выборе проектировщика (проведении тендера) задание предоставляется всем участникам конкурсной процедуры.
5.11 Проектировщик согласовывает задание при принятии его к исполнению, но не позже даты вступления в силу договора на проектирование. Не допускается согласование задания до его утверждения.
Согласование задания разрешается оформлять отдельным документом (письмом). В этом случае под грифом «Согласовано» делают ссылку на этот документ.
5.12 В случае если при согласовании задания на проектирование или в процессе проектирования проектировщик обнаружит в этом документе положения, применительно к защищаемому объекту противоречащие положениям принятых технических регламентов, или выяснит необходимость разработки СТУ, он обязан мотивированно сообщить об этом заказчику.
Указанные недостатки должны быть устранены до начала работ по проектированию, или работы по проектированию должны быть приостановлены в части выявленных недостатков.
5.13 В случае если после принятия задания к исполнению, но до даты фактического направления проектной документации на экспертизу, вступают в силу более высокие требования к проектируемой системе безопасности, то в задание и при необходимости в договор подряда должны быть внесены соответствующие изменения.
Обоснованные изменения могут быть оформлены отдельным протоколом, который является неотъемлемой частью задания. В этом случае на титульном листе всех экземпляров задания должна быть сделана ссылка на этот документ.
6 Состав документа «Задание на проектирование технической системы безопасности»
6.1 Состав (структура) задания определяется требованиями настоящего стандарта.
6.2 В составе задания в общем случае следует предусматривать разделы и подразделы, перечисленные в таблице 1. При этом в таблице 1 указаны номера пунктов настоящего стандарта, в которых сформулированы требования к соответствующему разделу (подразделу) задания.
4
Таблица 1 — Состав документа «Задание на проектирование» |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Окончание таблицы 1 |
|||||||||||||||||||||||||||||||||||||||||
|
6.3 Разделы и подразделы, не упомянутые в таблице 1 как «обязательные» при применении настоящего стандарта, являются рекомендуемыми.
6.4 Если требования, которые должны быть включены в какой-либо обязательный раздел (обязательный подраздел) задания, заказчиком не предъявлены, то в данном разделе (подразделе) указывается, что эти требования не установлены либо должны быть определены в процессе проектирования и дополнительно утверждены заказчиком.
6.5 Разработчик задания может при необходимости вводить в задание дополнительные разделы и/или подразделы.
Примечание — В обоснованных случаях, в зависимости от особенностей конкретной системы и от специфики защищаемого объекта, допускается объединять разделы (подразделы) и/или оформлять отдельные разделы (подразделы) в виде приложений.
6.6 Разработчик задания может при необходимости выполнять деление отдельных разделов на подразделы (и дополнительно деление подразделов на пункты).
7 Содержание разделов документа «Задание на проектирование технической системы безопасности»
7.1 Содержание раздела «Общие сведения»
7.1.1 Содержание подраздела «Общие данные»
В данном подразделе указывают:
а) полное и сокращенное наименования проектируемой системы и условное обозначение (код) системы;
б) полное наименование объекта защиты, на который будет установлена проектируемая система, местоположение (адрес) объекта;
в) обозначение (шифр) проекта (договора) строительства объекта;
г) вид строительства (новое, реконструкция, капитальный ремонт) и плановые сроки строительства;
д) наименование организации-заказчика;
е) наименование организации — разработчика задания на проектирование;
ж) наименование организации-проектировщика (указывается при принятии задания к исполнению и его согласовании);
и) полное наименование договора на проектирование с указанием номера и даты (указывается только после даты вступления договора в силу, при обращении задания в документообороте; допускается указывать на титульном листе сверху справа с обозначением задания в качестве приложения к договору).
Речь идет о системе контроля и управления доступом. То есть это комплекс программных, аппаратных средств контроля и управления, которые призваны установить определенный порядок доступа лиц и транспортных средств на территорию того или иного объекта. Она реализуется, в том числе, с помощью сигнализаций, специальных пропусков, сети контрольно-пропускных пунктов и проходных. Очевидно, способ, порядок и применяемые программно-аппаратные средства сильно зависят от специфики конкретного объекта — на разных зданиях и территориях безопасность организована по-разному.
Именно поэтому, закупая систему безопасности, заказчику следует внимательно разрабатывать техническое задание на техническую охрану, опираясь на реалии объекта, на который она закупается. В техзадании конкретизируются важные характеристики и параметры закупаемой системы, к нему госзаказчик вправе приложить необходимые визуальные иллюстрации, например чертежи и схемы. При этом, составляя техническое задание на охранную сигнализацию, госзаказчик обязан учитывать правила ст. 33 Федерального закона от 05.04.2013 № 44-ФЗ, в которой указаны правила описания объекта закупки.
Структура техзадания на систему безопасности нормативно не установлена, заказчик разрабатывает ее в зависимости от того, что ему необходимо описать, чтобы покупка прошла оптимально.
Порядок работы над техзаданием не регламентирован нормативно, каждый заказчик определяет его для себя самостоятельно. Порядок, в котором составляется техзадание СКУД, следующий:
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Полное наименование систем и их условное обозначение.
Полное и краткое наименование систем: Система контроля и управления доступом (далее — Система).
1.2. Шифр темы или номер договора (контракта).
Номер договора:
1.3. Плановые сроки выполнения работ.
Срок поставки оборудования и программного обеспечения и выполнения работ – не более 5 месяцев.
1.4. Источники и порядок финансирования работ.
Источником финансирования являются собственные средства Заказчика.
Порядок финансирования определяется условиями договора.
1.5. Требования к исполнителю.
1.5.1. Исполнитель должен обладать статусом сертифицированного партнера группы компаний «ААМ Системз» (www.aamsystems.ru) и иметь право осуществлять поставку, монтаж и пуско-наладку оборудования Apollo и программного обеспечения LyriX с наличием соответствующих обученных специалистов. Перед заключением договора Участник закупки обязан предоставить подтверждающие документы: копии действительного сертификата или информационного письма производителя, копии действительных сертификатов сотрудников, копии трудовых договоров сотрудников.
1.5.2. Исполнитель должен обладать статусом авторизованного партнера компании «Системы Флагман» (www.stss.ru) с возможностью перепродажи серверного оборудования STSS Flagman конечным пользователям. Перед заключением договора Участник закупки обязан предоставить подтверждающие документы: копия действительного сертификата или информационного письма производителя.
1.5.3. Исполнитель должен иметь в штате специалистов с сертификатами об успешном прохождении обучения по направлению «Техническая защита конфиденциальной информации» (не менее 1-го специалиста). Перед заключением договора Участник закупки обязан предоставить подтверждающие документы: копия действительного сертификата и трудового договора сотрудника.
1.5.4. В случае несоответствия требованиям пп. 1-3 п. 1.5 Технического задания Участник закупки будет признан уклонившимся от заключения договора.
2. НАЗНАЧЕНИЕ И ЦЕЛИ РАБОТ
2.1. Назначение Системы.
Система предназначена для:
- контроля и управления доступом сотрудников и посетителей в здание и внутренние помещения, экстренной автоматической разблокировки дверей в случае пожара;
- обнаружения и своевременного оповещения службы охраны о попытках несанкционированного проникновения в здание и его помещения.
2.2. Цели работ.
Целями работ является:
- поддержание работоспособности Системы в целом;
- обеспечение возможности масштабирования Системы;
- повышение надежности работы Системы;
- расширение функциональных возможностей Системы.
Данные цели должны быть достигнуты путем:
- замены устаревшего и выработавшего свой ресурс центрального сервера Системы на новый;
- замены устаревших и выработавших свой ресурс автоматизированных рабочих мест операторов/администраторов;
- обновления устаревшей и неподдерживаемой производителем версии программного обеспечения LyriX 4.3 на новую версию 5.3 с предоставлением технической поддержки в течение 18 месяцев;
- обновления прошивок и перенастройки оборудования (контроллеров APOLLO) для работы с новой версией LyriX;
- формирования ЗИП оборудования Системы.
3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
«Существующее программное обеспечение»: существующая на объекте Система, внедренная и принятая в эксплуатацию в 2010 г., работает под управлением программного обеспечения LyriX версии 4.3 производства компании «ААМ Системз» и включает в себя подсистему контроля и управления доступом и подсистему охранной сигнализации.
«Существующее техническое обеспечение»: аппаратная инфраструктура Системы построена на базе центрального сервера, управляющих контроллеров и интерфейсных модулей APOLLO, настенных считывателей HID, биометрических считывателей, охранных извещателей и др.
Полная спецификация существующего оборудования и программного обеспечения Системы и смежных систем приведена в Приложении № 2 к Техническому заданию.
4. ТРЕБОВАНИЯ К СИСТЕМЕ
4.1. Требования к Системе в целом.
4.1.1. Требования к структуре и функционированию Системы.
4.1.1.1. Перечень подсистем, их назначение и основные характеристики:
- подсистема контроля и управления доступом;
- подсистема охранной сигнализации;
- подсистема контроля и управления доступом Комплексной системы безопасности прилегающей территории;
- подсистема интеграции.
Подсистема контроля и управления доступом осуществляет доступ сотрудников и посетителей в здание и внутренние помещения, архивирование событий, учет рабочего времени, работу бюро пропусков, выполняет экстренную автоматическую разблокировку дверей в случае пожара.
Подсистема охранной сигнализации осуществляет обнаружения несанкционированного проникновения на объект с помощью извещателей, работающих на различных физических принципах, а также выполняет своевременное оповещение службы охраны о тревожных событиях.
Подсистема контроля и управления доступом Комплексной системы безопасности прилегающей территории осуществляет доступ автомобилей на территорию и подземную парковку объекта.
Подсистема интеграции обеспечивает взаимодействие со смежными системами, с которыми Система обменивается информацией и данными.
4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы.
Подсистемы в процессе функционирования должны осуществлять обмен информацией посредством существующей на объекте Защищенной структурированной кабельной системы (ЗСКС) и ЛВС департамента безопасности Заказчика.
4.1.1.3. Требования к характеристикам взаимосвязей Системы со смежными системами.
Модернизируемая Система должна иметь возможность программного или аппаратного взаимодействия (обмена информацией о тревожных событиях) с существующей системой автоматической установки пожарной сигнализации на базе пожарной станции ESSER и с системой мониторинга пожарной охраны на базе АРМ «Орион».
4.1.1.4. Требования к режимам функционирования Системы.
Система должна поддерживать следующие режимы функционирования:
- основной режим, в котором подсистемы выполняют все свои основные функции;
- профилактический режим, в котором одна или все подсистемы не выполняют своих функций.
В основном режиме функционирования Система должна обеспечивать:
- работу пользователей в режиме 24 часа в день, 7 дней в неделю (24×7);
- выполнение своих функций в режиме 24 часа в день, 7 дней в неделю (24×7).
В профилактическом режиме Система должна обеспечивать возможность проведения следующих работ:
- техническое обслуживание;
- модернизацию аппаратно-программного комплекса;
- устранение аварийных ситуаций.
4.1.1.5. Требования по диагностированию Системы.
Для всех технических компонентов Системы необходимо обеспечить регулярный и постоянный контроль состояния и техническое обслуживание.
4.1.1.6. Перспективы развития Системы.
Система должна реализовывать возможность дальнейшего расширения и модернизации как программного обеспечения, так и аппаратных средств.
4.1.2. Требования к численности и квалификации персонала Системы.
Численность и квалификация персонала Системы должны определяться с учетом следующих требований:
- структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала;
- структура Системы должна предоставлять возможность управления всем доступным функционалом Системы как одному администратору, так и предоставлять возможность разделения ответственности по администрированию между несколькими администраторами;
- для администрирования Системы к администратору не должны предъявляться требования по знанию всех особенностей функционирования элементов, входящих в состав администрируемых компонентов Системы;
- аппаратно-программный комплекс Системы не должен требовать круглосуточного обслуживания и присутствия администраторов у консоли управления.
4.1.4. Требования к надежности.
Система должна сохранять работоспособность и обеспечивать восстановление своих функций при возникновении следующих внештатных ситуаций:
- при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезапуска ОС и запуска исполняемого файла Системы;
- при ошибках в работе аппаратных средств (кроме носителей, данных и программ);
- при ошибках, связанных с программным обеспечением (ОС и драйверы устройств).
4.1.5. Требования к безопасности.
Все внешние элементы технических средств Системы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь зануление или защитное заземление в соответствии с ГОСТ 12.1.030-81 и ПУЭ.
Система электропитания должна обеспечивать защитное отключение при перегрузках и коротких замыканиях в цепях нагрузки, а также аварийное ручное отключение.
Общие требования пожарной безопасности должны соответствовать нормам на бытовое электрооборудование. В случае возгорания не должно выделяться ядовитых газов и дымов. После снятия электропитания должно быть допустимо применение любых средств пожаротушения.
Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов Системы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т. д.), не должны превышать действующих норм.
4.1.6. Требования к эргономике и технической эстетике.
Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав Системы, должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс Системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования оконной системы. Ввод-вывод данных Системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям Системы.
4.1.7. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы.
Условия эксплуатации, а также виды и периодичность обслуживания технических средств Системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации завода-изготовителя (производителя) на них.
4.1.8. Требования к защите информации от несанкционированного доступа и конфиденциальной информации.
Система должна обеспечивать защиту от несанкционированного доступа и конфиденциальной информации.
Компоненты защиты должны обеспечивать:
- идентификацию пользователя;
- проверку полномочий пользователя при работе с Системой;
- разграничение доступа пользователей на уровне задач и информационных массивов.
4.1.9. Требования по сохранности информации при авариях.
Программное обеспечение Системы должно восстанавливать свое функционирование при корректном перезапуске аппаратных средств.
4.1.10. Дополнительные требования.
Работы должны быть выполнены без длительных перерывов в функционировании существующих систем объекта.
Дополнительно Подрядчиком должно быть обеспечено:
- формирование запаса ЗИП оборудования в объеме, перечисленном в Приложении № 1 к Техническому заданию;
- техническая поддержка Заказчика (по телефону или электронной почте в рабочее время) в течение 18 месяцев с даты окончания работ.
4.2. Требования к видам обеспечения.
4.2.1. Требования к программному обеспечению Системы.
При проведении работ необходимо максимально эффективным образом использовать существующее программное обеспечение, как серверное, так и для рабочих станций.
4.2.2. Требования к техническому обеспечению.
Техническое обеспечение Системы должно максимально и наиболее эффективным образом использовать существующие у Заказчика технические средства, перечисленные в Приложении № 2 к Техническому заданию.
При выполнении работ по модернизации Системы обеспечить поставку и внедрение оборудования и программного обеспечения, перечисленного в Приложении № 1 к Техническому заданию.
5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ
Поставка оборудования и программного обеспечения и работы по модернизации Системы выполняются в три этапа:
Этап 1. Поставка оборудования и программного обеспечения.
Этап 2. Подготовительные работы по модернизации:
- Обновление прошивок на всех контроллерах APOLLO.
- Резервное копирование базы данных, конфигурации и всех настроек Системы.
- Настройка нового сервера (тестирование, проверка и настройка операционной системы).
- Конвертация старой базы данных LyriX в новую базу данных.
- Настройка новой базы данных LyriX.
- Отключение, демонтаж центрального сервера Системы и замена его на новый.
- Замена 5 (пяти) автоматизированных рабочих мест оператора/администратора на новые.
- Настройка новых АРМов (тестирование, проверка и настройка операционной системы).
Этап 3. Основные работы по модернизации:
- Установка и настройка ядра системы LyriX сервера.
- Установка и настройка комплекта функциональных модулей.
- Обновление пользовательских приложений (управляющая консоль и утилиты).
- Обновление рабочих мест операторов/администраторов.
- Обновление интеграционных драйверов Системы.
- Настройка Системы для обмена данными со смежными системами.
- Проведение индивидуальных испытаний компонентов Системы.
- Проведение комплексных испытаний.
6. УСЛОВИЯ ПРОИЗВОДСТВА РАБОТ
Работы выполняются на действующем объекте, в стесненных условиях, преимущественно в вечернее и ночное время, в выходные дни.
7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ
Сдача-приемка осуществляется комиссией, в состав которой входят представители Заказчика и Подрядчика.
8. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
ЭТАП |
ДОКУМЕНТ |
---|---|
Этап 1. Поставка оборудования и программного обеспечения |
Накладная ТОРГ-12 |
Этап 2. Подготовительные работы по модернизации |
Акт сдачи-приемки выполненных работ по Этапу 2 |
Этап 3. Основные работы по модернизации |
Акт сдачи-приемки выполненных работ по Этапу 3 |
9. ИСТОЧНИКИ РАЗРАБОТКИ
Настоящее Техническое задание разработано на основе следующих документов и информационных материалов:
- ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»;
- ГОСТ 24.701-86 «Надежность автоматизированных систем управления»;
- ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды»;
- ГОСТ 21958-76 «Система «Человек-машина». Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования»;
- ГОСТ 12.1.004-91 «ССБТ. Пожарная безопасность. Общие требования»;
- ГОСТ Р 50571.22-2000 «Электроустановки зданий».
10. ПРИЛОЖЕНИЯ
Настоящее Техническое задание включает в себя следующие приложения, являющиеся его неотъемлемой частью:
Приложение № 1 — Спецификация поставки — на 1 листе.
Приложение № 2 — Перечень существующего оборудования — на 9 листах.
ПРИЛОЖЕНИЕ № 2
Перечень существующего оборудования
Таблица 1. Перечень оборудования СКУД
№ п/п |
Наименование оборудования |
Тип, марка оборудования |
Количество, шт. |
СКУД |
|||
1 |
Сервер, стоечное (19”) исполнение |
HP ProLian DL120 G6 X3430 Pluggable SATA EU Svr |
1 |
2 |
Комплект памяти HP 2GB 2Rx8 PC3-10600E-9 Kit |
HP 2GB 2Rx8 PC3-10600E-9 Kit |
2 |
3 |
Оптический привод |
HP DL360G6 12.7mm SAtA DVD-RW Kit (for use with 4 bay severs only) |
1 |
4 |
ПО Microsoft Windows |
ОС Microsoft Windows server 2008 |
1 |
5 |
ПО |
Radmin server |
1 |
6 |
ПО LyriX Server в составе: ядро комплекса; аппарат реакций; генератор отчетов; базу данных пользователей; модуль отображения событий в списке; разработку и печать бэджей; графические планы объекта |
1 |
|
7 |
Драйвер пожарной сигнализации ESSER для панели 8007/8, IQ8 |
LyriX-ESSER-F |
1 |
8 |
Драйвер IP-системы видеонаблюдения Axis Communications |
LyriX-Axis |
1 |
9 |
Персональный компьютер |
HP 6000 Pro MT Core2Duo E8500, 2GB DDR3 PC3-10600(dlchnl), 500GB SATS HDD, DVD+/-RW, crdrdr, kbd/mse, GigLAN, WinX PPro+Win7+MSOfRe (repl NN487EA, NA569EA) |
2 |
10 |
Монитор |
Монитор 20 Samsung TFT |
2 |
11 |
Smart-карты iCLASS |
iC2004 |
2000 |
12 |
Дополнительное рабочее место для регистрации посетителей с автоматизацией процесса ввода и обработки документов. В составе: ПО для регистрации посетителей и выдачи гостевых карт; ПО для распознавания документов Cognitive Scanify API (паспорт, водительское удостоверение); сканер формата А5 (для паспортов) |
LyriX Workstation Cognitive |
1 |
13 |
Пакет лицензий на 5 дополнительных рабочих мест |
LyriX Workstation Package 5 |
1 |
14 |
Сетевой контроллер для управления доступом и охранной сигнализацией для подключения до 96 устройств |
AAN-100 |
6 |
15 |
Сетевой интерфейс к AAN-100 |
ANI-100 |
6 |
16 |
Преобразователь Ethernet/ RS-485 для подключения охранных панелей AIО-168 к контроллеру AAN-100 |
ENI-110 |
20 |
17 |
Драйвер для подключения AIM-4SL к контроллеру |
ASM-48 |
17 |
18 |
Интерфейсный модуль для подключения 4 считывателей/клавиатур с возможностью локального хранения базы карт и событий. |
AIM-4SL |
100 |
19 |
Преобразователь RS-485/Ethernet для подключения AIМ-4SL к контроллеру AAN-100 |
ЕNI-100 |
100 |
20 |
Патч-корд UTP, Cat.5е, 8 м |
Hyperline PC-SPM-UTP-RJ45-RJ45-C5e-8M |
98 |
21 |
Универсальный шкаф с замком, датчиком вскрытия корпуса, блоком питания + аккумулятор СПБ-12-1,0+DJW12-4.5 |
СБП-12-1,0 +DJW12-4.5 |
105 |
22 |
Блок питания импульсный |
БПИ-60-12-5 |
101 |
23 |
Считыватель бесконтактных карт iClass |
R-40 |
364 |
24 |
Дактилоскопический считыватель |
V-Flex 4G (smart) |
10 |
25 |
Бесконтактный радиочастотный считыватель дальнего радиуса действия для парковки |
LR-3 PassMan |
2 |
26 |
Бесконтактная радиочастотная метка |
MarkTag MeM |
300 |
27 |
Прозрачный держатель для крепления меток MarkTag MeМ |
WinFix Mem |
300 |
28 |
Кнопка выхода металл, цвет серебро, 86×50 |
АТ-Н800А |
403 |
29 |
Шлагбаум в комплекте со встроенным блоком управления и ломающейся стрелой длиной 4 м, время открывания 3 с |
ЕS 40 |
2 |
30 |
Приёмник одноразовых пропусков «Гоблин» модели OMA-43.606 |
OMA-43.606 |
1 |
31 |
Многозонный арочный металлодетектор |
PD-650i |
1 |
32 |
Шкаф настенный 19” |
WZ-2733-01-S1-011 (SU-104) 4U, 223×600×400 со стеклянной дверью, с открывающимися стенками |
7 |
33 |
Шкаф настенный 19” |
WZ-2733-01-S2-011 (SU-106) 6U, 312×600×400 со стеклянной дверью, с открывающимися стенками |
1 |
34 |
Модуль подключения коммутатора |
H3C 1000BASE-T SFP 0231A085 |
2 |
35 |
Бесконтактный RFID считыватель, идентификация пассивных меток на расстоянии до 10 м с комплектом для настенного монтажа. Поддержка стандарта ISO 18000 Gen 2 |
uPass Target |
4 |
36 |
Кронштейн для крепления считывателя на вертикальную мачту круглого для TRANSIT Ultimate, uPASS Target |
Mounting Kit Pole |
2 |
37 |
Козырек для защиты считывателя от дождя и солнечных лучей для uPASS Target |
Weather Hood 1 |
3 |
38 |
Компактная пассивная метка для крепления на внутренней стороне ветрового стекла автомобиля с расстоянием считывания до 10 метров |
UHF Windshield Tag |
300 |
39 |
Пассивная метка стандарта ISO размером с кредитную карту, расстояние считывания — до 10 метров |
UHF ISO Card |
700 |
40 |
Крепеж для метки Compact Tag на ветровое стекло автомобиля на присосках |
Tag Holder Pad |
300 |
41 |
СКАТ-2400. Блок бесперебойного питания 24В, 3.5А. Корпус под АКБ 2×12 А•ч. 3 индикатора и 3 информ. выхода, защита выхода от перегрузки и КЗ, защита АКБ от глубокого разряда, КЗ и переполюсовки, контроль наличия АКБ, холодный пуск |
СКАТ-2400 |
3 |
42 |
Аккумулятор 12В 12 А•ч (SF 1212) Security Force. Аккумуляторная батарея свинцово-кислотная |
6 |
|
43 |
Apollo AIM-4SL. Интерфейсный модуль для 4 считывателей с ЛБД без драйверов |
AIM-4SL |
1 |
44 |
Apollo ENI-100 Apollo. Сетевой интерфейс Ethernet 10 Base-T к интерфейсным модулям AIM-4SL, AIM-2SL,AIM-1SL и охранным панелям AIO. |
ENI-100 |
1 |
45 |
Apollo СБП 12-1,0 Apollo. Универсальный шкаф с замком, датчиком вскрытия корпуса, блоком питания для установки охранных панелей ProSYS. |
СБП-12-1,0 |
1 |
46 |
Аккумулятор 12В 4.5 А•ч (SF 12045) Security Force. Аккумуляторная батарея свинцово-кислотная |
4,5А/ч |
4 |
СОС: |
|||
1 |
Драйвер системы управления доступом и охранной сигнализацией APOLLO для контроллеров AAN-100. |
LyriX-APOLLO |
1 |
2 |
Пакет лицензий на 5 дополнительных рабочих мест |
LyriX Workstation Package 5 |
1 |
3 |
Сетевой контроллер для управления доступом и охранной сигнализации для подключения до 96 устройств |
AAN-100 |
1 |
4 |
Сетевой интерфейс к AAN-100 |
ANI-100 |
1 |
5 |
Преобразователь Ethernet /RS-485 для подключения охранных панелей AIO-168 к контроллеру AAN-100 |
ЕNI-110 |
4 |
6 |
Драйвер для подключения AIM-4SL к контроллеру |
ASM-48 |
4 |
7 |
Охранная панель |
AIO-168 |
26 |
8 |
Преобразователь RS-485/Ethernet для подключения AIM-4SL к контроллеру AAN-100 |
ЕNI-110 |
26 |
9 |
Терминатор линии (оконечное устройство), 10 кОм |
АТМ-30 |
430 |
10 |
Патч-корд UTP, Cat.5e, 8м |
Hyperline PC-SPM-UTP-RJ45-C5e-8M |
30 |
11 |
Универсальный шкаф с замком, датчиком вскрытия корпуса, блоком питания + аккумулятор |
СБП-10-1.0 + DJW12-4.5 |
29 |
12 |
Извещатель охранный объемный комбинированный (микроволновый + оптико-электронный) |
MX-40QZ |
323 |
13 |
Извещатель инфракрасный пассивный |
RX-40QZ |
6 |
14 |
Извещатель врезной магнитоконтактный для металлических конструкций, D 19 мм |
ИО 102-6 |
324 |
15 |
Извещатель магнитоконтактный врезной для деревянных конструкций, D 9 мм |
ИО 102-5 |
222 |
16 |
Извещатель охранный поверхностный вибрационный. |
“Vibro” |
31 |
17 |
Извещатель тревожный ручной с фиксацией (тревожная кнопка) |
Мод.269 |
6 |
Таблица 2. Перечень оборудования пожарной сигнализации
№ |
Наименование оборудования |
Кол-во, шт |
||
1 |
FX808397. Пожарная контрольная панель ESSER FlexEs Control FX18 на 2-18 слотов Honeywell |
1 |
||
2 |
FX808324. Пульт управления с QVGA-дисплеем для панелей ESSER FlexEs Control Honeywell |
1 |
||
3 |
018006. Аккумулятор 12В/ 24Ач Honeywell |
2 |
||
4 |
FX808322. Платформа расширения 1 с четырьмя слотами для панелей FlexEs Control Honeywell |
2 |
||
5 |
FX808323. Платформа расширения 2 с четырьмя слотами для панелей FlexEs Control Honeywell |
2 |
||
6 |
FX808332. Модуль кольцевого шлейфа с гальванической развязкой для панелей FlexEs Control Honeywell |
17 |
||
7 |
FX808341. Микромодуль ESSERNET для КП FlexEs Control, 500 kBd Honeywell |
1 |
||
8 |
«Honeywell». Светодиодное табло на 32 индикатора |
1 |
||
9 |
«Honeywell». Извещатель пожарный дымовой IQ8Quad |
1432 |
||
10 |
«Honeywell». Извещатель пожарный тепловой IQ8Quad |
2 |
||
11 |
«Honeywell». Извещатель пожарный ручной |
36 |
||
12 |
«Honeywell». Корпус ручного извещателя (металл) |
6 |
||
13 |
«Honeywell». Корпус ручного извещателя (пластик) |
29 |
||
14 |
Коробка разветвительная УК |
70 |
||
15 |
Резервированный источник питания |
8 |
||
16 |
Аккумулятор 12 В, ёмкость 7 А/ч |
16 |
||
17 |
Транспондер на 4 входных и 2 выходных реле |
15 |
||
18 |
784856. Последовательный интерфейс essernet(R) EDP двунаправленный, без корпуса |
1 |
||
19 |
784840.10. Микромодуль Essernet для КП IQ8Control, 62,5 kBd, до 16 абонентов в сети, макс. расстояние между соседними абонентами — 1000 м. |
1 |
||
20 |
772386. Модуль SEI RS232/V24, последовательный модуль essernet |
1 |
||
21 |
788606. Отдельный корпус для модуля 784856 |
1 |
||
22 |
013610.10. Базовый модуль WINMAGplus |
1 |
||
23 |
013626.10. Разрешение на опцию системы пожарной сигнализации |
1 |
||
24 |
013631.10. Модуль WINMAG, базовое разрешение, USB-ключ |
1 |
||
25 |
013625.10. Модуль WINMAG. Разрешение клиентской станции |
1 |
||
26 |
13652. Разрешение на опцию клиентских полномочий |
1 |
||
27 |
789860. Стартовый комплект для программирования |
1 |
||
28 |
МБП-12 (вар. 2.0). Малогабаритный блок питания |
1 |
||
29 |
12 В, 1,2 Ач. Аккумулятор герметичный свинцово-кислотный |
1 |
||
30 |
Системный блок Microsoft Windows 7 Профессиональная SP1 32&64-bit Рус |
2 |
||
31 |
Монитор 19″ |
2 |
||
32 |
Клавиатура |
2 |
||
33 |
Genius XScroll Optical Wheel Mouse мышь |
2 |
||
34 |
ИБП APC BX650CI-RS Back-UPS RS |
1 |
||
35 |
TRENDnet Кабель-адаптер USB AM —> COM9M 0.6м. |
1 |
||
36 |
Espada Кабель-адаптер USB AM —> COM9M / 25M |
1 |
||
37 |
Orient Кабель-переходник USB AM -> COM9M |
1 |
||
Таблица 3. Перечень оборудования Системы контроля и управления доступом Комплексной системы безопасности прилегающей территории
№ п/п |
Наименование и техническая характеристика |
Код оборудования, изделия, материала |
Завод-изготовитель |
Единица измерения |
Количество |
1 |
2 |
3 |
4 |
5 |
6 |
Центральное оборудование |
|||||
|
Контроллер для систем управления доступом и охранной сигнализации для подключения до 96 считывателей |
AAN-100 |
Apollo |
шт. |
1 |
|
Сетевой интерфейс к AAN-100 и AAN-32: Ethernet; 10 BASE-T & AUI |
ANI-100 |
Apollo |
шт. |
1 |
|
Драйвер порта RS-485 |
ASM-48 |
Apollo |
шт. |
10 |
|
Терминатор для интерфейса RS-485 |
ATM-48 |
Apollo |
шт. |
4 |
|
Сетевой интерфейс Ethernet 10 BASE-T |
ENI-100 |
Apollo |
шт. |
3 |
|
Интерфейсный модуль для подключения 4 считывателей/клавиатур с возможностью локального хранения базы карт и событий |
AIM-4SL |
Apollo |
шт. |
6 |
|
Универсальный шкаф с замком, датчиком вскрытия корпуса, блоком питания для установки |
СБП-12-1.0 |
шт. |
7 |
|
|
Аккумулятор для установки в СБП-12-1.0 |
DJW12-4.5 |
шт. |
7 |
|
Оборудование проходной |
|||||
|
Турникет с сервоприводом. Корпус и штанги из нерж. стали. Питание 220 |
TPB-E02 |
KABA |
компл. |
2 |
VAC. Установка на готовый пол |
|||||
|
Операционная панель для управления турникетами тип 2, цифровой интерфейс |
OPL-5 |
KABA |
шт. |
2 |
|
Корпус для накладного крепления операционной панели |
OPL |
KABA |
шт. |
2 |
|
Считыватель бесконтактных Smart-карт с расстоянием считывания до 11.4 см (только чтение) |
R40 |
HID |
шт. |
5 |
|
Приемник одноразовых пропусков |
OMA-43.606 |
ОМА |
шт. |
1 |
Оборудование въездов и парковки |
|||||
|
RFID-считыватель активных меток с расстоянием считывания до 10 м |
LR-6XL |
TagMaster |
шт. |
6 |
|
Считыватель бесконтактных Smart-карт с расстоянием считывания до 11.4 |
R40 |
HID |
шт. |
2 |
|
Шлагбаум в комплекте со встроенным блоком управления, стрелой прямоугольного длиной 8 м и системой аварийной остановки (или открытия) стрелы, время открывания 8.5 с |
ES 80 |
ELKA |
компл. |
2 |
|
Внешнее электромеханическое устройство аварийного открытия шлагбаума ключом, с установкой |
EmKeySw |
ELKA |
шт. |
2 |
|
Одноканальный приемник, встраиваемый в блок управления шлагбаума |
EKX1OF |
ELKA |
шт. |
2 |
|
Одноканальный передатчик SKX1LC с программируемым кодом, «ухо» для крепления на брелок для ключей |
SK-Midi-1 |
ELKA |
шт. |
4 |
|
Антенна для приемника (коаксиальный кабель длиной 8 м) |
ANT-8 |
ELKA |
шт. |
2 |
|
Усилитель радиосигнала с функцией защиты от помех |
Repeater TRCKX |
ELKA |
шт. |
2 |
|
Фиксированная опора для стрелы |
Support |
ELKA |
шт. |
2 |
|
Встраиваемый в корпус шлагбаума нагреватель (45 W) |
Heating |
ELKA |
шт. |
2 |
|
Встраиваемый термостат к нагревателю |
Thermostat |
ELKA |
шт. |
2 |
|
Пара фотоэлементов, дальность 10м (24Vdc) |
Cell-10 |
ELKA |
шт. |
2 |
|
Комплект сигнальных огней (4 шт.) на прямоугольные стрелы для шлагбаумов ELKA всех типов. Двухцветные светодиоды (горят красный/зеленый) при движении стрелы или в положении «закрыто» (или мигают) красным, в состоянии «открыто» — зеленым, заводская установка |
LED LightingB |
ELKA |
шт. |
1 |
|
Светофор двухсекционный (красный, зеленый) |
SEM-02 |
Stagnole |
шт. |
5 |
|
Индукционная петля периметром 6 м, длина подводящего провода 12 м |
IndLoop-6 |
ELKA |
шт. |
2 |
|
Контроллер индукционной петли одноканальный |
DetLoop-1 |
ELKA |
шт. |
2 |
|
Панель для одного шлагбаума |
Desktop-1 |
ELKA |
шт. |
2 |
|
Дорожное сферическое зеркало 630 |
Mirror630 |
шт. |
1 |
|
Рабочие места и программное обеспечение |
|||||
|
АРМ |
компл. |
2 |
||
|
Монитор HP TFT 19″ LE1901w |
NK570AA |
HP |
компл. |
2 |
|
Дополнительное рабочее место |
LyriX Workstation |
компл. |
2 |
Таблица 4. Перечень оборудования аппаратно-программного комплекса ИСО «Орион» на базе АРМ «Орион Про»
№ |
Наименование оборудования |
Марка оборудования |
Кол-во, шт |
---|---|---|---|
1. |
Сервер «Орион Про». Программное обеспечение. Сервер системы «Орион Про» с ключом защиты. |
Сервер «Орион Про» |
1 |
2. |
Оперативная задача «Орион Про» исп.127, Программное обеспечение. Программное обеспечение (одно ядро и один монитор) и ключ защиты |
Оперативная задача «Орион Про» исп.127 |
1 |
3. |
Администратор базы данных «Орион Про», Программное обеспечение |
Администратор базы данных «Орион Про» |
1 |
4. |
Монитор «Орион Про», Программное обеспечение. Рабочее место с функциями управления и отображения информации по сети |
Монитор «Орион Про» |
1 |
5. |
ПЭВМ C5000 |
C5000 |
2 |
6. |
Монитор 19″ |
E1920NR |
2 |
7. |
Клавиатура |
KB-8310-BL-UR |
2 |
8. |
Genius XScroll Optical Wheel Mouse мышь |
XScroll Optical Wheel Mouse |
2 |
9. |
ИБП APC BX650CI-RS Back-UPS RS |
UPS 650VA Back RS APC |
1 |
10. |
Orient XWT-PS050 (RTL) PCI, Multi I / O, 2xCOM9M Контроллер последовательного интерфейса |
XWT-PS050 (RTL) PCI, Multi I / O, 2xCOM9M |
1 |
11. |
D-Link 5-port Desktop Switch (5UTP, 10 / 100Mbps) |
DES-1005A |
2 |
12. |
Адресный расширитель |
АР-8 |
5 |
13. |
Контролер двухпроводной линии |
С2000-КДЛ |
1 |
14. |
Устройство коммутационное |
УК-ВК/02 |
11 |
15. |
Источник вторичного электропитания |
СКАТ-1200Б |
5 |