Что нужно учесть ещё?

Прошлая часть статьи о техническом задании на проектирование вызвала большой интерес среди Вас, уважаемые читатели Low-voltage Blog. Мне было очень приятно, что вы оставляли комментарии о хорошей проработке технического задания в социальных сетях и группах блога. Но никто как то не обратил внимание, что это была только первая часть 😉 . В прошлый раз мы успели рассмотреть самое основное — двигаясь от задач видеоконтроля составили список контролируемых зон, задали для каждой зоны минимально достаточные параметры видео потоков на «просмотр» и на запись, а так же параметры записи. Сегодня рассмотрим ещё ряд важных параметров, которые можно учесть в техническом задании на проектирование.

Более подробная новая статья по заданию на проектирование / ТЗ — Задание на проектирование — важнейший документ на который все плюют.

Содержание:

1. Ограничения на выбор оборудования
1.1 Требования по доступности функций системы видеонаблюдения в течении заданного времени
1.2 Требования по коэффициенту окупаемости инвестиций ROI (Return On Investment) либо по совокупной стоимости владения TCO (total cost of ownership)
1.3 Требования к масштабируемости решения и/или защите инвестиций при дальнейшем расширении системы
1.4 Требование по использованию в проекте существующего оборудования
1.5 Требования по интеграции IT-систем и систем безопасности с системой видеонаблюдения
2. Удобство эксплуатации и обслуживания
2.1 Эргономика рабочих мест оператора. Использование оператора при просмотре «живого» видео
2.2 Работа с архивом записей видеонаблюдения
2.3 Экспорт записей во вне
2.4 Удобство обслуживания
3. Требования к оформлению документации

Кому адресован этот блог и почему моему мнению можно доверять.

Мои контакты — пишите по любым интересующим вопросам, в том числе предложения о сотрудничестве.

Внимание! Статья содержит много информации и потребует время на изучение. Для удобства посетителей моего блога планируется создание видео-обзора данной темы на собственном канале youtube. Следите за новостями в блоге!

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

Почему это важно сделать? Задание на проектирование переводит язык бизнес-требований к системе видеонаблюдения, сформулированный в концепции, в язык технических требований к системе, количественным показателям, KPI — если KPI не было сформулировано на этапе концепции.

1. Ограничения на выбор оборудования

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

У собственника есть требования по доступности функций системы видеонаблюдения в течении заданного времени
У собственника есть требования по коэффициенту окупаемости инвестиций ROI (Return On Investment) либо по совокупной стоимости владения TCO (total cost of ownership)
У собственника есть требования к масштабируемости решения и/или защите инвестиций при дальнейшем расширении системы
У собственника есть пожелание / требование по использованию в проекте существующего оборудования
У собственника есть требования по интеграции IT-систем и систем безопасности с системой видеонаблюдения (либо наоборот видеонаблюдения со слаботочными системами)

Проектировщик, пристегнутый наручниками к батарее.

В задании на проектирование бывает полезно задать границы свободы выбора технических решений для проектировщика

1.1 Требования по доступности функций системы видеонаблюдения в течении заданного времени

В России данное требования в задании на проектирование видеонаблюдения (и вообще «слаботочке», исключая связь) встречается чуть чаще, чем никогда (видимо потому что мало кто об этой «фиче» знает). Я столкнулся почти случайно, работая в ЗАО «Нефтегазоптимизация» над скандальным проектом трассы М11 участок 15-58. Для данного проекта мне «по служебной необходимости» и требованию консультантов-французов концессионера нужно было доказать расчётом, что проектируемая нами система видеонаблюдения (а она была не просто большой, а экстремально большой — порядка 1500 камер) укладывается в заданный коэффициент готовности (Instantaneous availability function — в наших нормах ГОСТ 27.002-89). Ничего сложного посчитать коэффициент готовности нет, кроме одного нюанса — нужно собрать среднюю наработку на отка́з (англ. Mean time between failures, MTBF) и среднее времени восстановления (англ. Mean time to repair MTTR) для отдельных узлов системы видеонаблюдения. Задача не всегда тривиальная, но сейчас я объясню в чём польза данного требования.

Я уже подробно описывал в статье «Надёжность систем безопасности и слаботочных систем» все определения и формулы расчёта, поэтому не буду повторяться, а расскажу на примере нашего бара-ресторана, как это можно использовать.

Теперь давайте рассуждать. В прошлый раз мы составили и согласовали с Заказчиком список задач видеонаблюдения. Какие задачи для собственника будут наиболее критичными? Думаю связанные с расследованием инцидентов. Т.е. это задачи записи архива. Допустим мы готовы мириться со сбоями в системе видеонаблюдения, приводящими к потерям записи не чаще 1 дня за 30 дней. Kг =(T – tпΣ) /T, где tпΣ — суммарное время простоя, а T — заданный интервал времени. Kг=(30-1) /30=0,9667. Это такой не слишком «суровый» коэффициент готовности (не 0,99 и тем более не 0,999). С нашим небольшим количеством оборудования (всего 12 камер видеонаблюдения) мы отсекаем только совсем уж ненадежное.

Для упрощения допустим, что Заказчик решил разбить весь проект на два пусковых комплекса (по нашему совету, т.к. не вписался в бюджет). Запись на первом этапе идёт только на встроенные карты памяти microSD/microSDHC/microSDXC. Таким образом, для записи необходимо соблюсти условие работоспособности самой камеры и одновременно карты памяти.

K_{г сист.} =(K_{г камеры} * K_{г карты})¹²

MTBF запрашиваем у производителя или берем из datasheet -ов, у кого указаны (мягко говоря мало кто эти данные вывешивает в открытый доступ, нашёл вот у не совсем профильной для камер компании Moxa — аж 541,826 hours — немного странные цифры, обычно на порядок меньшие). Но т.к. сам лично запрашивал эти данные у многих компаний (Bosch, Pelco, Siemens, Panasonic и др.) то с уверенностью могу сказать что они существуют, особенно у европейских компаний (хотя и у нашего «родного» Болида — к их чести — эти данные есть для многих изделий, только искать нужно в руководствах по эксплуатации).

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

Давайте считать. K_{г камеры}=(50,000 hours) / (50,000 hours + 24 hours) = 0,9995

Нормальная (не бытовая) карта памяти типа SanDisk microSD/microSDHC/microSDXC имеет наработку на отказ MTBF >1,000,000 hours.

K_{г карты}=(1,000,000 hours) / (1,000,000 hours + 24 hours) = 0,9999

В итоге для нашего случая K_{г сист.} =(0,9995*0,9999)¹²= 0,993

Т.е. 50,000 hours для камеры — это с запасом, можно взять и по-меньше либо подешевле посмотреть карты памяти.

А теперь представьте, что камер у нас уже 100.

В итоге для нашего случая K_{г сист.} =(0,9995*0,9999)¹⁰⁰= 0,9417

Т.е. уже меньше требуемых нам 0,9667.

А ведь мы получили с цифрами в руках подтверждение очень понятной «житейской» мудрости — если берешь одну камеру себе на дачу — можешь брать Китай или наш OEM не заморачиваясь — и даже будет работать. Если берешь камеру для своего малого предприятия — бери тот же Китай, но уже по-лучше, по-надежней и по-дороже (сами понимаете о ком я 😉 ). А если у тебя большой бизнес центр — изволь купить «брендовое» well-known оборудование. Но не из-за престижа, а просто чтобы твоя достаточно крупная система была надежна не хуже малой системы на более дешёвом оборудовании.

С таким подходом можно с цифрами в руках объяснять Заказчику (или наоборот подрядчику) к чему приведет «тупая» не просчитанная экономия на оборудовании. Хотите сэкономить? Да кто же вам мешает! Только подпишитесь сразу на снижение уровня доступности (проще — времени работоспособности) функций системы. Нужно по-надежней? Ищите «узкие» места системы и вводите резервирование, покупайте на склад ЗИП и держите на объекте обученный персонал, чтобы уменьшить MTTR.

Присмотритесь к коэффициенту готовности. Он позволяет сделать очень много выводов из нескольких «циферок». Очень крутая «штука» для обоснования технических решений.

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

Чем больше в системе «узлов» и чем больше элементов, влияющих на выполнение конкретных функций системы видеонаблюдения, — тем менее надежна система в целом. Если совсем упрощать — чем больше камер в системе, тем менее надежна вся система в целом.
Исходя из п.1 — чем крупнее система — тем более надежные узлы необходимо использовать при её проектировании. Тем важней выявлять и резервировать «узкие» места в работе системы. Тем важней наличие ЗИПа.
«Переплачивая» за «бренд» вы как правило получаете более надежное оборудование. Дискуссионный конечно момент, но с цифрами сложно спорить. Пример — казалось бы Pelco — отличное оборудование, что ещё нужно? Зачем брать Bosch — только переплачивать 😉 Но сравните MTBF у Bosch и у Pelco. И думаю уже не будете столь категоричными 🙂 .

1.2 Требования по коэффициенту окупаемости инвестиций ROI (Return On Investment) либо по совокупной стоимости владения TCO (total cost of ownership)

Коэффициент окупаемости инвестиций ROI (Return On Investment), так же как и совокупная стоимость владения TCO (total cost of ownership) — важные индикаторы для любого бизнес-проекта.

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

Совокупная стоимость владения TCO — важный для более широкого круга заказчиков коэффициент. И я совершенно не понимаю, почему о нём забывают и никак не учитывают при заказе видеонаблюдения собственники предприятий. В данном коэффициенте «сидит» одновременно и ограничения на стоимость создания системы «сверху» (чтобы не было не обоснованного использования дорогого оборудования), и требование к надежности оборудования и соответственно ограничения на стоимость обслуживания системы. У меня правда кейсов применения данных показателей так же нет. Очень прошу коллег, кто имел дело с ROI и TCO поделиться своим опытом в комментариях.

1.3 Требования к масштабируемости решения и/или защите инвестиций при дальнейшем расширении системы

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

Рисунок - на заднем плане футуристические башни, звездолеты, на переднем - старенькая уставшая, но ещё работающая камера (седая, с грустными глазками и опущенными ручками).

При заказе системы видеонаблюдения неплохо подумать о сроке эксплуатации

О чём вообще речь и о каких проблемах я говорю?

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

Чтобы не быть голословным, приведу такой пример. Сейчас существуют 4 типа стандартов видеонаблюдения: аналоговые телевизионные стандарты NTSC, PAL; IP-видеонаблюдение с пакетной передачей данных; цифровые телевизионные стандарты высокой чёткости HD-SDI, 3G-SDI (и др.); аналоговые стандарты высокой чёткости HD-CVI Dahua, HD-TVI Hikvision (Techpoint), AHD NextChip. Если у заказчика в планах расширение системы лет через 5 то я бы не решился ему советовать брать оборудование на цифровых телевизионных стандартах высокой чёткости либо аналоговых стандартов высокой чёткости. Просто потому, что данные стандарты ещё очень молоды и активно развиваются. Предугадать, какой из них «выстрелит», а какой «сгинет» в конкурентной борьбе с собратьями — невозможно. Отсюда риски вложиться в систему, которую затем будет сложно или невозможно масштабировать, расширять и в конечном счёте даже поддерживать в рабочем состоянии.

1.4 Требование по использованию в проекте существующего оборудования

Я имею ввиду вполне понятное желание Заказчика по-максимуму использовать то, что уже есть и во что вложены деньги. Самый распространённый случай — заказ расширения существующей системы видеонаблюдения. Либо использование существующей кабельной инфраструктуры. Либо локальной сети передачи данных (что для видеонаблюдения далеко не всегда возможно без существенной переделки этой самой локальной сети). Либо есть какое то серверной оборудование.

В техническом задании на проектирование видеонаблюдение данное желание можно отразить как «Список существующего оборудования заказчика, доступного для применения в системе видеонаблюдения».

Для каждой единицы оборудования указать:

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

1.5 Требования по интеграции IT-систем и систем безопасности с системой видеонаблюдения

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

В техническом задании на проектирование видеонаблюдение данное желание можно отразить как «Список IT-систем и систем безопасности, подлежащих интеграции с системой видеонаблюдения«.

Для каждой системы указать:

используемое центральное (серверное) программное обеспечение (ПО), его версию, установленные service pack-и и т.п.;
наличие стандартных открытых протоколов (в том числе промышленных) или интерфейсов для обмена данными c внешними информационными системами (BACnet, LonWorks, Modbus (RTU), EIB/KNX; OPC (DA), SNMP; XML) либо API для интеграции;
список событий и команд, доступных для использования в сторонних информационных системах.

Приведу свой кейс, когда требование по интеграции видеонаблюдения было столь специфичным (такое бывает 😉 ), что с первого раза ставило в тупик тех. поддержку многих вендоров программного обеспечения для видеонаблюдения. А именно требовалась поддержка протокола LDAP (англ. Lightweight Directory Access Protocol ). Не так много компаний, куда я обращался вообще понимали, чего я от них хочу и зачем мне нужна такая странная «фишка». А смысл был в том, что пользователи системы видеонаблюдения Заказчика, помимо нашей системы, должны были авторизовываться в ещё целом перечне разных систем (там и безопасность, и специфическое программное обеспечение контроля платности для автомагистрали, и IT системы). И если система видеонаблюдения не поддерживала технологию, автоматизирующую процесс авторизации в разных приложениях — то какая бы замечательная она не была — Заказчику она бы не подошла. Такие моменты редко, но всё же встречаются, их стоит учитывать.

2. Удобство эксплуатации и обслуживания

Один из пунктов, о котором так же забывают, хотя он важен и влияет в конечном счёте на проектирование. Давайте для начала разберемся с эксплуатацией. От видеонаблюдения нам, в основном, нужны три вещи: удобный просмотр «живой картинки» с камер, удобный поиск по архиву и удобный экспорт видео фрагмента во вне.

Всем очень советую посмотреть один любопытный документ — «UK police requirements for digital cctv systems» (Требования полиции Британии для цифровых систем видеонаблюдения). Нашим уважаемым экспертам, составляющим отраслевые нормативные документы нужно учиться у коллег Соединенного Королевства. Краткий, чёткий, технически и организационно грамотный документ.

2.1 Эргономика рабочих мест оператора. Использование оператора при просмотре «живого» видео

Оператор видеонаблюдения - труженик невидимого фронта :-)

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

В Рекомендациях МВД Р 78.36.008 — 99 (Проектирование и монтаж систем охранного телевидения и домофонов) даны довольно чёткие рекомендации по размещению мониторов, советую пользоваться именно ими. Хотя, возможно, для кого то актуальней будут видеостены 😉 . Привожу цитату нужного пункта:

4.3.3 Количество и расположение мониторов

В информационном поле рабочего места оператора различают три зоны:

Зона 1 — с углами обзора ± 15° по горизонтали и вертикали.

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

Зона 2 — с углами обзора ± 30° по горизонтали и вертикали.

В этой зоне располагают часто используемые мониторы, требующие менее точного и быстрого анализа информации (например различения). В зоне 2 может быть размещено от 12 до 27 мониторов;

Зона 3 — с углами обзора ± 60° по горизонтали и вертикали.

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

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

при потолочном освещении помещения, в котором расположены видеомониторы, рекомендуется устанавливать на экраны козырьки (чтобы оператор не увеличивал яркость и контраст изображения на мониторе);

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

не допускать попадания на экран монитора прямого или отраженного света от ярких источников. Нельзя располагать мониторы напротив окна или источников яркого искусственного освещения.

Немного устаревшая картинка. Зато классика жанра :-)

Схема рабочего места оператора

Я бы добавил от себя требования по видео-потокам с камер на рабочие места оператора и требования по автоматизации действий персонала:

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

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

2.2 Работа с архивом записей видеонаблюдения

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

Система единого времени локальной сети видеонаблюдения. Вроде бы при чём тут архив? На самом деле не стоит забывать про необходимость настройки NTP / SNTP — сервера в системе видеонаблюдения, иначе об эффективной работе с архивом можно забыть. Время на записях с разных камер без их синхронизации и привязке к GMT может различаться, что при расследовании инцидентов вызовет дополнительные трудности (увеличение времени на расследование и т.п.).
Безопасность данных. Много аспектов — архив должен быть не доступен для злоумышленников как физически (за счёт расположения, контроля доступа), так и информационно (авторизация пользователей, разделение прав доступа, логи действий авторизованных пользователей в архиве, информационная безопасность). Резервирование / дублирование записей архива, о чём мы упоминали в первой части. Защита от подделки записи. «Если для регистрации видео используется файловая система (на регистраторе или компьютере — не важно), то есть риск монтажа записи. Внедрите систему электронной цифровой подписи — и при использовании видео как доказательства к вам будет меньше вопросов» — Денис Юрьевич Михайлов, эксперт Экспертно-криминалистический центр МВД России. Защита от случайного «затирания» отмеченного важного фрагмента записи более свежими записями до момента экспорта во вне. И обратная ситуация — защита от остановки процесса записи из-за переполнения архива «помеченными» записями (кстати может быть и преднамеренной — саботаж пользователя — поэтому важно хранить уже упоминавшиеся логи).
Глубина архива. Она должна быть достаточна для решения конкретных задач расследования инцидентов. Думаю разумно разделять требования к глубине архива по категориям решаемых конкретной зоной наблюдения задач, как мы это и делали в прошлый раз. В тех же «Требованиях полиции Британии для цифровых систем видеонаблюдения» п.8 есть такая рекомендация: «The system should have sufficient storage capacity for 31 days good quality pictures.» А вы решайте сами, советовать что-либо сложно.
Разрешение, степень компрессии изображения, кадровая частота видео. Англичане советуют (и это выглядит очень разумно) использовать «переменное» качество видеоматериала в зависимости от срока его хранения — максимальное разрешение и частота кадров и минимальная компрессия на первом этапе (первые 24 часа) сменяется на постепенное увеличение компрессии и уменьшении кадровой частоты (до 31 дня хранения). Железо и софт должны поддерживать такой функционал и это интересная тема для будущего исследования 😉 .
Поддержание качества исходного видеоматериала на заданном уровне. Речь о банальном поддержании заданного угла обзора камеры, фокуса, глубины резкости, чистоты линзы объектива и т.п. мелочах. По сути — об нормальном техническом обслуживании системы видеонаблюдения. Да, это тоже влияет на работу с архивом! Чтобы было с чем работать. А не как у нас повсеместно 😉
Интеллектуальный поиск по архиву, а так же функции «ускорения» просмотра архива. Речь о метках, которые создает предварительно настроенная система видеонаблюдения в архиве при фоновом анализе видео (пересечение линий, поиск оставленных предметов и др. функции видеоаналитики — не все из них работают так, как утверждает реклама, но это отдельная тема). И о функциях типа Time Compressor^® от ITV | AxxonSoft или Video Synopsis^®от BriefCAM.
Удобство работы с архивом. Скорость перемотки, просмотр в режиме «кадр за кадром», просмотр в режиме «мультиокна» (одновременно кадров с нескольких камер; вот почему важна синхронизация по времени), поиск по времени и дате, удобное отображение времени и даты на самой записи и при экспорте «стоп кадров».

2.3 Экспорт записей во вне

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

Обучение операторов. Права на экспорт. Смешной момент, но забывать про него не стоит. Надо определить кто из пользователей имеет право на экспорт записей и с каких именно камер и банально обучить его грамотно пользоваться данной функцией. При этом user guide по пользованию основных функций системы (в том числе и экспорта) должен храниться локально на объекте и быть доступным для использования. Кроме того, оператор должен понимать механизм «замещения» более старых записей более новыми. Знать время, через которое запись скорее всего будет удалена Уметь ставить соответствующие метки, предотвращающие «затирание» нужных записей. И не забывать убирать данные метки после успешного экспорта фрагмента во вне.
Длительность экспорта больших фрагментов. Метки даты и времени, цифровые подписи. Важный параметр. Система видеонаблюдения должна «уметь» экспортировать большие фрагменты видео с включенными в видео метками даты и времени (и при возможности цифровыми подписями) за адекватное время. Оператор должен знать необходимое время для экспорта небольших фрагментов (до 15 минут), средних (до 24 часов) и крупных (вплоть до полного архива) для планирования своих действий. Метод экспорта, используемый видеонаблюдением, должен быть адекватен размеру архива, хранимого в дисковом массиве системы.
Формат видео. Система должна позволять экспортировать видеофрагменты в любом поддерживаемом видеонаблюдением разрешении в общеупотребительном формате видео, не требующем переконвертации либо других дополнительных действий для просмотра на встроенных в операционную систему пользователя плеерах видео.
Экспорт логов событий и журнала системы. Для проведения расследований может потребоваться экспорт логов действий оператора и состояния системы в определенный период. Видеонаблюдение должно поддерживать данный функционал.
Поддержка удобных внешних носителей информации. Система должна позволять экспортировать видео фрагменты на удобные пользователю носители. Например, внешние жёсткие диски, USB-флешки, CD/DVD/Blue-Ray.

2.4 Удобство обслуживания

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

Наличие достоверной исполнительной документации.
Наличие паспортов на оборудование.
Наличие другой документации, упрощающей обслуживание, ремонт, выявление проблем (различные журналы обслуживания и ремонта и т.п.)
Ограничение и контроль доступа к центральному оборудованию.
Расположение центрального оборудования в серверных или др. специализированных помещениях.
Монтаж центрального оборудования в шкафы и стойки (электрические, 19″).
Возможность отключения части центрального оборудования без необходимости отключать всю систему.
Защита оборудования от скачков напряжения, разрядов молнии, электромагнитных помех (там где это целесообразно).
Использование клемм, разъемов, патч-панелей, кроссов, органайзеров и т.п., позволяющее легко подключать и отключать части оборудования.
Использование стандартов СКС при прокладке кабелей (там где это целесообразно).
Использование коммутационных коробок, розеток и модулей Keystone Jack и т.п. для подключения периферийного оборудования.

Скорее всего что-нибудь забыл. Пишите в комментариях, добавлю.

Главное — чтобы об этих «мелочах» вспоминали не при эксплуатации, а ещё при планировании системы.

3. Требования к оформлению документации

Заказчику необходимо указать в задании на проектирование систем видеонаблюдения требования к составу и содержанию документации (для рабочей документации — обязательно, для разделов 6, 11, 5 и 9 проектной документации — желательно при финансировании из средств застройщика / собственника), к оформлению документации, количеству экземпляров и наличию электронной копии, прочие условия заказчика по разработке документации (например требование приложить сертификаты пожарной безопасности на оборудование и материалы).

Я подробно описывал всю подноготную проектной и рабочей документации в своих статьях (смотри тут и здесь), поэтому не буду повторяться. Не забываем так же про требование авторского надзора проектировщика и требование составить перечень предоставляемой производителем работ исполнительной документации (согласно РД 11-02-2006) и приемо-сдаточной документации.

Мы затронули только часть вопросов, обозначенных в статье «Как создать систему видеонаблюдения. Шаг 2. От концепции к заданию на проектирование«. И тем не менее вы видите, какой это большой объём работ. Обычно его выполняет «бесплатно» подрядчик по строительству. А теперь ответьте в коментариях и группах блога в социальных сетях — кто выполняет все пункты данной статьи 🙂 . И можно ли их выполнить «за просто так» качественно. Это мой вопрос к вам для размышления на досуге.

На сегодня эта вся информация, которой я хотел с вами поделиться, спасибо за уделенное время!

В статье использована иллюстрации, специально подготовленная для блога моей супругой Озеровой Екатериной. Катенька, большое спасибо за помощь и поддержку!

В статье использованы результаты моделирования в Axis Camera Extension for SketchUp® 3D. Хочу поблагодарить Marek Pavlica (Regional Communications Specialist Russia, CIS & Eastern Europe, Axis Communications) и Denis Lyapin Technical, Trainer — Axis Communications за всестороннюю помощь и поддержку, благодаря которой публикация стала возможной.

Уважаемые читатели блога, если Вы заметили в статье неточность, сложность в изложении материала либо некорректность используемых терминов — прошу написать в комментариях либо в личном сообщении, все замечания будут обязательно учтены и по-возможности исправлены все недочёты.

Жду ваших вопросов, комментариев и предложений.

Жмите кнопки социальных сетей, подписывайтесь на email рассылку, добавляйте блог в свою RSS-ленту, вступайте в группы блога в социальных сетях!

Все материалы данного блога принадлежат его автору. Использование без ссылки на данный блог с указанием авторства не допускается!

Похожие статьи

Техническое задание на проектирование видеонаблюдения. Часть 2