Как составить задание на проектирование видеонаблюдения?

Данная статья выпускается специально в рамках 3-го набора моего курса Проектирование систем видеонаблюдения — как обещанную «раздатку» на «домашки». Ее явно не хватало на прошлых потоках — и вот теперь она есть. В статье я собрал «бинго» типовых ошибок проектировщиков при составлении задания на проектирование. При этом статья содержит выжимку множества моих заметок в канале Telegram Проектирование видеонаблюдения, куски ГОСТа, мои вебинары и выступления, а также часть ранее выпущенных статей по теме. Думаю данный материал будет интересен и другим людям — поэтому решил его выложить публично. Мне нет смысла его скрывать — основная ценность курса ведь не в теории (которой уже довольно много), а в практике и моей обратной связи по ней. Надеюсь, что материал, представленный в статье — послужит широкому кругу заказчиков и проектировщиков систем видеонаблюдения.

Задание на проектирование и «театр безопасности»

А нужно ли вообще при планировании видеонаблюдения обсуждать с заказчиком задачи видеонаблюдения и согласовывать задание на проектирование?

Зачастую ведь на практике этого не происходит! Приходит заказчик — говорит мне нужно видеонаблюдение, камер поставьте 50, вот таких. Глубина архива — 30 суток. И чтоб мертвых зон не было! И выводите все камеры на видеостену — чтобы весь объект как на ладони!

Пару охранников — достаточно. Там правда ещё смены придется формировать — охрана нужна круглосуточная. Ещё и обслуживать кому то надо систему — мои балбесы не справятся)

Вот и все ТЗ. Что мы узнали из него о задаче заказчика? Ничего! Но можем ли мы по этому «заданию» сформировать технико-коммерческое предложение (ТКП)? Конечно! Вообще нет проблем! И большинство коллег именно так и поступают — и по-своему правы. Они же не обманывают клиента, делают ровно то, что он от них требует.

В итоге мы получаем «театр безопасности» во всей своей неприглядной «красе». Обсуждение с заказчиком задач наблюдения — это защита от «театра безопасности». Вот для этого мы эту тему и поднимаем.

Распределение ролей между Заказчиком и проектировщиком

Работая с партнёрами, курсантами Такир и студентами — я долго не мог понять, почему так сложно даётся задача составления задания на проектирование. И вот недавно понял.

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

ОТР (основные тех. решения)

отвечают на вопрос «как»
опираются на расчеты
учитывают требования норм
ориентированы на монтаж / пусконаладку
оформляются в виде проектной / рабочей документации (в редких случаях — эскизного проекта и др.)

Эксплуатационные требования

отвечают на вопрос «зачем»
содержат критерии решения целевых задач наблюдения
опираются на планы дальнейшей эксплуатации, обслуживания, расширения, масштабирования и модернизации системы
ориентированы на эксплуатацию (в том числе процедуру приемки системы)
оформляются в виде концепции безопасности и задания на проектирование (пояснение ниже)

Слайд с презентации по типовым ошибкам — Какие документы использовать для формирования эксплуатационных требований 1 и 2 уровня

Эксплуатационные требования можно разделить на 2 уровня:

1 уровень раскрывает задачу заказчика и обосновывает применение конкретной системы (видеонаблюдения например) в сравнении с альтернативными вариантами (например охранной сигнализацией).

В России эксплуатационные требования 1 уровня — это концепция безопасности.

2 уровень раскрывает требования к эксплуатации системы, аспектам ее менеджмента, обслуживания, модернизации и т.д.

Эксплуатационные требования 2 уровня в России — это и есть задание на проектирование!

Задание на проектирование — как организовать процесс?

Нужна большая разъяснительная работа с заказчиком. Нельзя ставить телегу впереди лошади — перед разработкой непосредственно самого задания на проектирование требуется зафиксировать существующую ситуацию на объекте в плане обеспечения безопасности и планы ее изменения. Первым разрабатываемым документом должна стать Концепция безопасности объекта хотя бы в каком то примитивном виде — как резюме совещания например всех заинтересованных от заказчика сторон. В Концепции нужно описать как сейчас решаются вопросы обеспечения безопасности объекта, какую роль будет играть видеонаблюдение. Кто, где и когда будет использовать получаемые с камер данные
Добиться от заказчика актуальных исходных данных (подробнее об этом далее)
На основании п.1 и п.2 можно предварительно сделать эскизный проект, где рассчитать необходимое и достаточное число камер, места их установки и тактико-технические характеристики (ТТХ). Согласовать его с заказчиком
Выяснить планы на дальнейшую судьбу системы — как заказчик планирует ее эксплуатировать, обслуживать, расширять, модернизировать.
По ГОСТ Р 57839-2017 либо иному документу, содержащему требования к составу и оформлению задания на проектирование прописываем по п.1-4. Включать или нет эскизный проект — тут дело отношений с заказчиком. Обязательно прописываем критерии решения целевых задач наблюдения и методику тестирования системы при сдаче в эксплуатацию (подробнее об этом далее).

Типовые ошибки

Разбор типовых ошибок курсантов УЦ Такир

Требований к выбору способа обоснования, подтверждения и оценки соответствия проектных решений

Рассмотрим ГОСТ Р 57839-2017 Производственные услуги. Системы безопасности технические. Задание на проектирование. Общие требования. Вот некоторые выдержки:

7.4.1 Содержание подраздела «Требования к выбору способа обоснования, подтверждения и оценки соответствия проектных решений»

В данном подразделе в дополнение к ссылкам на требования технических регламентов заказчик указывает конкретный способ обоснования, подтверждения и оценки соответствия проектных решений, который должен быть применен при проектировании (либо выполнение требований документов в области стандартизации, на основании применения которых подтверждается выполнение требований технических регламентов <…>

7.4.2 Содержание подраздела «Перечень нормативных документов»

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

При необходимости заказчик может включать в указанный перечень соответствующие зарубежные и международные стандарты и своды правил или их отдельные разделы.

Положения всех документов или их отдельных разделов (частей), указанных в перечне нормативных документов задания, являются обязательными для применения при проектировании.

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

Это разумные требования. Давайте рассмотрим примеры фрагментов задания на проектирование, где они не соблюдаются.

Пример 1 Переложим всю ответственность на заказчика

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

Недостатки: Данные формулировки невозможно проверить при согласовании итоговой документации, ведь характеристики оборудования формально не связаны с решаемой целевой задачей наблюдения и берутся «из опыта» подрядчика, а не путем расчетов и сравнений с числовым критерием. Более того, сами задачи тут даже не обсуждаются. Получается, что задание на проектирование — просто снимает с проектировщика всякую ответственность за выполненную работу.

Пример 2 Отложим этот вопрос на этап проектирования

Требования должны быть определены в процессе проектирования и дополнительно утверждены заказчиком.

Недостатки: Задание на проектирование — это предпроектная часть работ, которая максимально очерчивает проектировщику круг возможных технических решений, ограничивая его. Совершенно не понятно что должно случится, чтобы вопрос, не решенный «на берегу», внезапно решился уже «в процессе», когда некогда договариваться, нужно проектировать.

Пример 3 Задачи без критериев их выполнения

качество записи: периметр – должно обеспечить круглосуточное и всепогодное обнаружение несанкционированного проникновения;
при приближении к зданиям и местам хранения ценностей на территории объекта система должна обеспечить качество видеонаблюдения и записи на уровне идентификации;
при входе в здания объекта, в коридорах стационаров система должна обеспечить качество видеонаблюдения и записи на уровне идентификации;
при проезде через КПП и при проходе – система должна обеспечить качество видеонаблюдения и записи на уровне идентификации номера автотранспорта и личности проходящего.

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

Давайте сформулируем принципы оценки проектных решений:

В задании на проектирование сформулированы целевые задачи наблюдения для каждой из зон наблюдения. Например: распознавание ГРЗ автотранспорта, распознавание и идентификация лиц, обнаружение вторжения в область или пересечения линии, классификация объектов наблюдения (например — человек, животное, легковое авто, грузовое авто0 и т.п. Описание таких целевых задач можно найти как в нормативных документах — Р 78.36.008-99 Рекомендации. Проектирование и монтаж систем охранного телевидения и домофонов; BS EN 62676-4:2015 Video surveillance systems for use in security applications Application guidelines либо в описании производителей видеоаналитических модулей.
В задании на проектирование сформулированы критерии выполнения целевых задач наблюдения путем ссылок на нормативные документы, собственные стандарты организации заказчика либо конкретные числовые параметры, взятые из технических описаний / спецификаций производителей видеоаналитических модулей. Примеры нормативных документов — BS EN 62676-4:2015 Video surveillance systems for use in security applications Application guidelines; «критерий Джонсона», Распоряжение Мингосуправления Московской области 10-80/РВ от 17.07.2018 «О внесении изменений в распоряжение Министерства государственного управления, информационных технологий и связи Московской области от 30 июня 2015 г. № 10-17/РВ «Об утверждении общих технических требований к программно-техническим комплексам видеонаблюдения системы технологического обеспечения региональной общественной безопасности и оперативного управления «Безопасный регион» при проектировании объектов Безопасного региона» и др.
Целевые задачи для каждой из зон наблюдения логически связаны с эксплуатационными требованиями 1 уровня, прописанными в Концепции безопасности объекта или ином верхнеуровневом документе.

Не прописана методика сдачи системы в эксплуатацию

В предыдущем пункте речь шла про оценку проектных решений на стадии сдачи заказчику / эксперту проектной или рабочей документации. Но этого недостаточно, ведь систему ещё нужно сдать в эксплуатацию после монтажа, наладки и опытной эксплуатации. Какими критериями работоспособности системы при этом руководствоваться — желательно решить ещё до выбора самих технических решений. Ведь видеонаблюдение не похоже на другие слаботочные системы — простая работоспособность ещё ничего не говорит о ее информативности и пригодности для решения поставленных целевых задач наблюдения.

7.7.4 Содержание подраздела «Требования к испытаниям при ПНР и на этапе опытной эксплуатации, комплексного опробования и ввода в эксплуатацию»

В данном подразделе устанавливают:

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

Отдельно следует упомянуть про состав, объем и методы испытаний системы на этапах ПНР и ввода в эксплуатацию. В наших нормах фактически нет четко описанных методик для сдачи системы видеонаблюдения в эксплуатацию. Можно говорить лишь про ГОСТ 19.301-79 Единая система программной документации (ЕСПД). Программа и методика испытаний. Требования к содержанию и оформлению. Однако где взять саму методику? Тут я могу советовать лишь зарубежные стандарты:

Performance Testing of CCTV. Perimeter Surveillance Systems. (Using the Rotakin Standard Test Target) — Тестирование производительности системы видеонаблюдения с помощью стандартной тестовой цели Rotakin от подразделения научных разработок МВД Великобритании (эта организация в Великобритании — типа НИЦ Охрана на максималках)

Тут ключевая идея — что цель стандартна, по размерам близка к фигуре человека, имеет в своем составе нечто вроде телевизионной испытательной таблицы, может вращаться вокруг оси для проверки времени экспозиции

BS EN 62676-4:2015 Video surveillance systems for use in security applications Application guidelines — Annex B (normative) Test protocol for video surveillance systems (VSS) target — Рекомендации по тестированию систем видеонаблюдения при помощи целей-имитаций лиц и автомобильных номерных знаков

Тут идея — проверка решения целевой задачи наблюдения — идентификации — с помощью стандартных тестовых лиц (3 расы по 3 лица, достаточно похожих, чтобы нужно было приложить усилие для идентификации). Лица показывают оператору (отдельно в живую и на записи), а он заносит результат идентификации в таблицу. Далее анализ — совпало / не совпало. Сейчас можно и алгоритмы так тестировать, не только оператором, будет объективнее.

Прямые указания на тактико-технические характеристики (ТТХ) оборудования, конкретные марки, число камер и др.

Это полностью исключает из процесса принятия основных технических решений по системе самого проектировщика — его роль в данном случае — обеспечить лишь работоспособность системы. Такой подход конечно допустим, но на мой взгляд лишает всякого смысла оформление проекта — это будет лишь отражение решения самого заказчика. Необходимость при этом проектировщика весьма сомнительна. Я уже как то подробно останавливался на этой теме в статье Задание на проектирование — важнейший документ на который все плюют, вот небольшая выдержка:

<…> Если сотрудники заказчика на столько квалифицированы, что способны сами выбрать места расположения камер и их технические характеристики для выполнения требований ТЗ по решаемой каждой камере задаче — то зачем вообще привлекать стороннюю компанию к проектированию? Тогда пусть они сами составят рабочий проект и именно по рабочему проекту (а не по ТЗ) — подрядчик будет производить монтаж и пусконаладку, а заказчик — принимать систему в эксплуатацию.

Необходимо «отделить мух от котлет» — требования от пути их реализации. В ТЗ нужно прописать именно требования, а как их достигнуть — это уже компетенция подрядчика, а никак не заказчика.

На это вы можете мне возразить — а как же быть, если у заказчика уже есть «любимое» оборудование, установленное на многих объектах? Разводить зоопарк? Конечно нет, на этот случай в задании на проектирование / техническом задании можно составить т.н. «вендор-лист» со списком разрешенных к использованию при проектировании / планировании марок либо даже конкретных моделей. При этом необходимо оставить возможность подрядчику мотивировано отказаться от использования «навязанных» моделей, если их применение не позволяет выполнить задачи видеонаблюдения в конкретной зоне. <…>

Согласно ГОСТ Р 57839-2017 п 7.5.4:

7.5.4 Содержание подраздела «Требования к применяемому оборудованию»

<…>

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

Для объектов, относящихся к перечню статьи 48.1 ГрК РФ, или если функциональные или технические параметры систем для данного объекта проектирования установлены принятыми техническими регламентами или иными обязательными для применения документами ФОИВ, не допускается включать в задание требования о применении конкретных видов оборудования, за исключением тех случаев, когда это предусмотрено соответствующим стандартом организации-заказчика. Указанный стандарт организации (или его часть, относящаяся к проектируемой системе) должен пройти экспертизу и получить положительное заключение профильного технического комитета по стандартизации, а также должен быть включен в подраздел «Перечень нормативных документов» задания согласно 7.4.2 настоящего стандарта.

В случае если при согласовании задания или в процессе проектирования проектировщиком выявлено несоответствие параметров и характеристик оборудования, рекомендованного заказчиком, требованиям нормативных документов применительно к конкретному объекту или с применением этого оборудования не могут быть выполнены иные предъявленные заданием технические требования, то проектировщик в соответствии с положениями 5.12 настоящего стандарта должен направить заказчику мотивированное обоснование невозможности применения указанного оборудования.

Решение о выборе конкретного оборудования при проектировании системы для достижения ее параметров и характеристик, указанных в задании, в технических регламентах и других документах обязательного применения, а также в документах, включенных в подраздел «Перечень нормативных документов» задания согласно 7.4.2 настоящего стандарта, принимает проектировщик и несет полную ответственность за соответствие выбранного оборудования требованиям, предъявляемым к системе.

Не указана решаемая системой задача и эксплуатационные требования

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

Пример 1 На столько общая задача, что из нее невозможно сделать практических выводов при проектировании

Назначение СОТ:

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

Недостатки: Тут за все хорошее, против всего плохого. Информация бесполезна для принятия конкретных проектных решений, а значит не несет никой ценности для проектировщика.

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

Нехватка исходных данных для проектирования

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

Проектирование — это процесс, на вход которого мы продаем исходные данные, а на выходе — получаем готовую документацию. Предпроектные работы занимают существенную долю общего времени работы над задачей заказчика. При этом они как правило не оплачиваются. Что демотивирует проектировщика выполнять их качественно.

Этот замкнутый круг можно было бы разорвать, применяя услуги внешнего консультанта или внутренней службы заказчика. Что доступно лишь крупным компаниям. А воля к этому есть вообще у единичных компаний, как правило с иностранным участием (в составе иностранных холдингов).

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

Вот ключевые сведения:

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

Кроме этого, существует ряд специфических особенностей объекта, которые могут повлиять на выбор технического решения. Эти особенности также стоит уточнить:

относится ли объект к особо опасным, технически сложным и уникальным объектам по ГрК
есть ли на объекте зоны, требующие взрывобезопасного или искрозащищенного исполнения оборудования
есть ли на объекте зоны с агрессивной окружающей средой — низкие температуры, повышенная влажность, наличие радиации, сильных электромагнитных полей, высокая коррозийность и т.п.
требования по антитеррористической защищённости объекта согласно законодательству (объекты транспорта, безопасные города / регионы, места массового скопления людей и др.)

Часто заказчик считает хорошим решением проблемы отсутствия исходных данных предпроектное обследование объекта. По моему опыту предпроектное обследование используют для уточнения актуальности предоставленных заказчиком исходных данных. Например:

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

При этом вопрос о том кто должен проводить предпроектное обследование — не однозначен. Есть как сторонники возложить эту функцию на проектировщика, так и противники такого подхода. Я отношусь ко вторым.

Я считаю, что обследовать объект должен или представитель заказчика, или представитель организации, которая возьмёт потом систему на тех. обслуживание. Или на крайний случай — бригадир монтажников, кто будет выполнять работы.

Почему проектировщик на обследовании — выброшенные деньги?

Ряд причин:

проектировщик на обследовании при отсутствии хорошей координации с управляющим объекта от заказчика или от обслуживающей организации будет большую часть времени находится в ожидании (ключей, разрешения на доступ, имеющейся документации и т.п.)
при обследовании проектировщик в любом случае будет ходить с представителем заказчика или обслуживающей организации. Делать фото и пометки «на салфетке». Тоже самое можно сделать и без проектировщика. Задача проектировщика — дать перечень нужных ему исходных данных.
у проектировщика нет данных о наличии и составе монтажного оборудования и планируемых способах организации строительства подрядчика, равно как и о регламентах обслуживания при проведении ТО. Поэтому учёт этих факторов в любом случае идёт со слов заказчика.
современные реалии проектного дела предполагают работу не в рамках одного региона (где проживает проектировщик), а по всей территории России. Поэтому применение проектировщика при обследовании — получается очень дорогим и неэффективным.

Нет требования к масштабированию, расширению и дальнейшей модернизации системы

Ещё одним аспектом, важным для крупных систем и не нужным для малых и средних — является возможность выбранное техническое решение масштабировать и стоимость этого масштабирования. Вполне возможно, что ТЗ пишется на «пилотный» объект заказчика — и в дальнейшем решение должно быть развернуто на остальных объектах. Это, согласитесь, сильно повлияет на возможные варианты решения в том числе и для пилотного объекта — нужно сразу заложиться под дальнейший рост системы.

Нет требований на сопряжение с другими системами

Часто система видеонаблюдения используется для верификации (подтверждения) событий от других систем: системы контроля и управления доступом (СКУД), охранной и пожарной сигнализации и др. Для охранных систем систем — это и интеграция с периметральными системами охранной сигнализации, когда при сигнале о проникновении на объект мы, прежде чем высылать группу захвата, верифицируем инцидент по системе видеонаблюдения. Другой пример — связка видеонаблюдения и СКУД на проходной, когда при считывании карты доступа на мониторе охранника появляется «живое» видео с привязанной к данному контроллеру камеры и «карточка» пользователя СКУД с фотографией, что позволяет охраннику проверить правомерность пользования данной картой конкретного посетителя (не была ли карта сотрудника передана лицу, не имеющему доступ на объект).

Более подробно тему интеграции видеонаблюдения и других слаботочных и IT смистем я рассматривал в статье Видеонаблюдение как часть интегрированной системы безопасности.

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

Согласно ГОСТ Р 57839-2017 п 7.5.3:

7.5.3 Содержание подраздела «Требования к системе по сопряжению с другими системами и оборудованием»

В данном подразделе приводят:

а) требования по взаимодействию создаваемой системы безопасности с другими техническими системами безопасности объекта, а также при необходимости с другими техническими средствами на объекте;

б) требования к параметрам и характеристикам взаимосвязей системы с другими системами, включая требования по быстродействию, в том числе указания об аппаратных и/или программных способах обмена информацией, требования по применяемым стандартным или иным интерфейсам передачи данных.

Но это далеко не так просто, как кажется на первый взгляд. Вспоминаю свой старый доклад по смежной теме, где перечислены основные проблемы этого пункта:

Интеграция видеонаблюдения с периметральной сигнализацией. Евгений Озеров, ITV, PROIPvideo2019

Не заданы требования к эксплуатации, обслуживанию и эргономике

Общая стоимость владения системой вовсе не равнозначна цене ее создания. Расходы на содержание системы, плановый и внеплановый ремонт, сотрудников, занятых эксплуатацией системы — могут значительно превосходить первоначальные вложения, о чем хорошо бы помнить при планировании системы.

Почти всегда одну и ту же задачу можно решить несколькими способами. При выборе какой способ использовать не всегда рационально руководствоваться только ценой создания системы. Часто копеечная экономия приводит к необоснованно дорогому обслуживанию системы в будущем.

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

Чек-лист как создать грамотное задание на проектирование видеонаблюдения

Ищем в закромах завалявшуюся концепцию безопасности на объект защиты или собираем тех. совет из тех, кто систему собирается использовать и фиксируем для чего конкретно она нужна и какую роль в общей защите объекта будет выполнять, кто и зачем будет использовать данные с камер.
Конкретизируем задачи до простых и понятных целевых задач наблюдения (определяем что является целью наблюдения, какая информация должна быть определена на видео — например обнаружение и классификация «чужого» или распознавание лица и т.п.).
Придумываем свои, а лучше — берём готовые из нормативных документов или документов производителей — критерии решения целевых задач наблюдения и обоснования проектных решений.
Собираем исходные данные для проектирования — планировки зданий, ген. план, расположение электрощитовых, серверных, кроссовых, сущ. лотков СКС и др. сущ. инженерных сетей, особенно если их нужно будет использовать для видео (ЛВС например объектовую, хотя это и не айс).
Продумываем аспекты менеджмента системы и требования к эксплуатации.
Планируем сроки дальнейшего расширения, масштабирования или модернизации.
Планируем сценарии взаимодействия с другими системами (интеграцию).
Оформляем всю информацию по стандартной форме — собственной (если есть стандарт организации) или одной из нормативных (например по ГОСТ Р 57839)

Вне рамок статьи

Статья и так получилась громоздкой — и возможно будет перерабатываться в будущем. Хочу отметить ряд моментов, которые остались вне ее рамок:

Часто (особенно для объектов нового строительства) задание на проектирование разрабатывается по Приказу Министерства строительства и жилищно-коммунального хозяйства Российской Федерации от 01.03.2018 г. № 125/пр «Об утверждении типовой формы задания на проектирование объекта капитального строительства и требований к его подготовке» к объекту проектирования в целом, без детальной проработки отдельных инженерных систем, в том числе и систем видеонаблюдения. Это большая глобальная проблема и ее можно обсудить отдельно.
За скобками оставляю ряд важных моментов, которые не требуется прописывать в каждом задании на проектирование, но на конкретном объекте они могут быть очень важными. В ГОСТ Р 57839-2017 большинство из них описано. Например — требования надежности, о чем у меня есть отдельная статья — Надёжность систем безопасности и слаботочных систем.
Понятно, что все хотят «рыбу» задания на проектирование — но пока не готов выкладывать в общий доступ свои наработки. К тому же есть планы их доработать. А вот на курсе они будут 😉

Другие статьи по теме: