Требования к платформе видеонаблюдения и видеоаналитики

advertisement
Требования к платформе
ВИДЕОНАБЛЮДЕНИЯ
Оглавление
1
ОБЩИЕ СВЕДЕНИЯ ..............................................................................................................................2
2
НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ..........................................................................3
3
ПЕРЕЧЕНЬ СОКРАЩЕНИЙ, ТЕРМИНОВ И ОПРЕДЕЛЕНИЙ ..................................................4
3.1
3.2
4
ПЕРЕЧЕНЬ СОКРАЩЕНИЙ............................................................................................................................................4
ПЕРЕЧЕНЬ ТЕРМИНОВ И ОПРЕДЕЛЕНИЙ .....................................................................................................................4
ТРЕБОВАНИЯ К СИСТЕМЕ ................................................................................................................7
4.1 ТРЕБОВАНИЯ К СИСТЕМЕ В ЦЕЛОМ............................................................................................................................7
4.1.1
Требования к структуре и функционированию системы ................................................................... 7
4.1.2
Требования к численности и квалификации персонала ....................................................................... 9
4.1.3
Показатели назначения ........................................................................................................................ 10
4.1.4
Требования к надежности ................................................................................................................... 12
4.1.5
Требования по безопасности программно-аппаратных средств системы .................................... 13
4.1.6
Требования к эргономике и технической эстетике .......................................................................... 14
4.1.7
Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов
системы 14
4.1.8
Требования к обеспечению безопасности информации ..................................................................... 15
4.1.9
Требования по сохранности информации при авариях ..................................................................... 16
4.1.10
Требования к защите от влияния внешних воздействий .................................................................. 16
4.1.11
Требования к патентной чистоте...................................................................................................... 17
4.1.12
Требования к стандартизации и унификации .................................................................................... 17
4.2 ТРЕБОВАНИЯ К ФУНКЦИЯМ (ЗАДАЧАМ), ВЫПОЛНЯЕМЫМ СИСТЕМОЙ.................................................................... 18
4.2.1
Требования к вычислительной подсистеме ........................................................................................ 18
4.2.2
Требования к подсистеме хранения данных ....................................................................................... 18
4.2.3
Требования к подсистеме сети передачи данных.............................................................................. 18
4.2.4
Требования к подсистеме виртуализации .......................................................................................... 18
4.2.5
Требования к подсистеме базовых инфраструктурных сервисов ................................................... 20
4.2.6
Требования к подсистеме резервного копирования и восстановления данных ............................... 22
4.2.7
Требования к подсистеме базовых функций видеонаблюдения ........................................................ 22
4.2.8
Требования к подсистеме обработки видеоизображений ................................................................ 26
4.2.9
Требования к подсистеме ведения архива .......................................................................................... 28
4.2.10
Требования к подсистеме трансляции видеоизображений .............................................................. 28
4.2.11
Требования к подсистеме протоколирования .................................................................................... 29
4.2.12
Требования к подсистеме мониторинга видеоизображений ........................................................... 30
4.2.13
Требования к подсистеме интеграции................................................................................................ 30
4.2.14
Требования к подсистеме ведения служебных реестров и справочников ....................................... 31
4.2.15
Требования к подсистеме видеоаналитических модулей (детекторов) ......................................... 33
4.3 ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ ..................................................................................................................... 37
4.3.1
Требования к информационному обеспечению ................................................................................... 37
4.3.2
Требования к лингвистическому обеспечению ................................................................................... 38
4.3.3
Требования к программному обеспечению.......................................................................................... 38
4.3.4
Требования к техническому обеспечению .......................................................................................... 38
4.3.5
Требования к метрологическому обеспечению .................................................................................. 40
4.3.6
Требования к организационному обеспечению ................................................................................... 40
4.3.7
Требования к методическому и другим видам обеспечения.............................................................. 40
1
Общие сведения
1.1 Полное наименование Системы
Cистема видеомониторинга МГТС.
1.2 Краткое наименование Системы
1.3 Заказчик
(далее - Заказчик).
1.4 Исполнитель
Определяется по результатам проведения конкурсной процедуры.
1.5 Основание для проведения работ
1.6 Плановые сроки проведения работ
Срок начала работ:
2
2
Назначение и цели создания системы
2.1 Назначение Системы
Система
предназначена
для
предоставления
услуг
видеомониторинга
(видеонаблюдения) для пользователей сегментов B2B, B2C.
Система предназначена для:
 сбора, обработки и хранения видеоизображений;
 предоставления доступа пользователям к видеоизображениям в режиме
реального времени и видеоархиву;
 обеспечения учета и технического обслуживания средств видеонаблюдения.
2.2 Цели и задачи работ
В ходе проведения работ по разработке Системы должны быть созданы следующие
подсистемы и/или модули Системы:
o вычислительная подсистема;
o подсистема хранения данных.
o подсистема сети передачи данных;
o подсистема виртуализации;
o подсистема базовых инфраструктурных сервисов;
o подсистема резервного копирования и восстановления данных;
o подсистема базовых функций видеонаблюдения;
o подсистема обработки видеоизображений;
o подсистема ведения архива видеоизображений;
o подсистема трансляции видеоизображений;
o подсистема протоколирования;
o подсистема мониторинга видеоизображений;
o подсистема интеграции;
o подсистема ведения служебных реестров и справочников.
o подсистема
видеоаналитических
модулей
модулей)
3
(детекторов/интеллектуальных
3
Перечень сокращений, терминов и определений
3.1 Перечень сокращений
Сокращение
Расшифровка
АРМ
Автоматизированное рабочее место
БД
База данных
ИБП
Источник бесперебойного питания
ИК - подсветка
ИС
Инфракрасная подсветка применяется в условиях плохой
освещенности
Информационная система
ЛВС
Локальная вычислительная сеть
НТП
Научно-техническая продукция
ПО
Программное обеспечение
СУБД
Система управления базой данных
СХД
Система хранения данных входящая в подсистему хранения
данных сервисной платформы
ТЗ
Техническое задание
ФС
Файловая система
ЭВМ
Электронно-вычислительная машина
API
Application programming interface - Интерфейс программирования
приложений
HLS
HTTP Live Streaming протокол передачи гипертекста
RTMP
Real Time Messaging Protocol проприетарный протокол
потоковой передачи данных
RTSP
Real Time Streaming Protocol Протокол потока реального времени
URL
Единый указатель ресурсов (англ. URL — Uniform Resource
Locator) — единообразный локатор (определитель
местонахождения) ресурса.
3.2 Перечень терминов и определений
4
Автоматизированное
рабочее
место
–
Программно-технический
комплекс,
обеспечивающий автоматизированный доступ к информации, обрабатываемой в Системе
через соответствующий интерфейс.
Прикладное ПО – программное обеспечение, представляющее собой совокупность
программ предназначенных для выполнения определенных пользовательских задач и
рассчитанное на непосредственное взаимодействие с пользователем.
Общесистемное ПО -
программное
обеспечение,
представляющее
собой
совокупность программных средств, разработанных ранее и не связанных непосредственно
с созданием Системы. Обычно общесистемное ПО представляет собой совокупность
программ общего назначения, предназначенных для организации вычислительного
процесса и решения часто встречающихся задач обработки информации.
Реестр эталонных изображений
-
специализированное
хранилище
данных
в
составе Системы, содержащее графические файлы и/или видеофрагменты, сделанные с
использованием средства видеонаблюдения после его фактического монтажа по месту и
направления в сторону базовой точки обзора объекта видеонаблюдения, в дневное время в
согласованное время года, с определенным уровнем освещенности и степенью
приближения, которые визуально рассматриваются и в результате формально принимаются
за эталонные для каждого отдельно взятого средства видеонаблюдения.
Базовая точка обзора средства видеонаблюдения
-
Положение
поворотного
управляемого средства видеонаблюдения и уровень приближения изображения, при
которых обеспечивается наиболее оптимальное отражение текущей ситуации с объекта
видеонаблюдения, то есть достигается максимальная степень приближения к эталонному
изображению.
Доступ к информации, обрабатываемой в Системе
организационно-технических
мероприятий
и
- Комплекс взаимосвязанных
программно-технических
средств,
обеспечивающих получение пользователями видеоизображений, получение и обработку
служебной информации о состоянии компонентов Системы, а также иной информации,
обрабатываемой в Системе.
Объекты видеонаблюдения
- Объекты, в отношении которых в установленном
порядке ведется видеонаблюдение.
Оператор Системы - Заказчик и (или) орган или организация, которому Заказчиком
переданы в установленном порядке отдельные операторские функции.
Персонал Оператора Системы - Сотрудники Оператора Системы или других
организаций, имеющих договорные отношения с Оператором Системы, обеспечивающие
эксплуатацию Системы в соответствие с установленными для них должностными
5
обязанностями. Состав, количество групп персонала, типы (роли) ответственности и
разграничения по ним определяются регламентами.
Реестр пользователей Системы,
содержащее
Специализированное
формализованные
хранилище
унифицированные
данных
описания
в
составе
сведений
о
пользователях информации, обрабатываемой в Системы.
Реестр средств видеонаблюдения -
Специализированное хранилище данных в
составе Системы, содержащее формализованные описания средств видеонаблюдения, их
возможностей и характеристик, необходимых для организации хранения и использования
видеоизображений в Системе
Средство видеонаблюдения – Техническое устройство, предназначенное для
осуществления видеонаблюдения за объектом видеонаблюдения, информация о котором
поступает
в
6
Систему.
4
Требования к системе
4.1 Требования к Системе в целом
4.1.1
Требования к структуре и функционированию системы
4.1.1.1 Перечень подсистем
Система видеонаблюдения
должна
состоять
из
следующих
функциональных
компонентов:

вычислительная подсистема;

подсистема хранения данных.

подсистема сети передачи данных;

подсистема виртуализации;

подсистема базовых инфраструктурных сервисов;

подсистема резервного копирования и восстановления данных;

подсистема базовых функций видеонаблюдения;

подсистема обработки видеоизображений;

подсистема ведения архива видеоизображений;

подсистема трансляции видеоизображений;

подсистема протоколирования;

подсистема мониторинга видеоизображений;

подсистема интеграции;

подсистема ведения служебных реестров и справочников.
4.1.1.2 Требования к способам и средствам связи для информационного обмена между
компонентами Системы
При решении указанных выше задач необходимо учитывать, что все программные
компоненты должны соответствовать стандартам обмена данными с использованием стека
протоколов TCP/IP.
Информационный обмен между программными компонентами подсистем должен
осуществляться с использованием стандартных протоколов и технологий.
Информационный обмен между программными компонентами подсистем Системы и
прикладным клиентским ПО должен осуществляться по протоколам HTTP и HTTPS.
4.1.1.3 Требования к режимам функционирования Системы
Все проектные решения должны учитывать требование круглосуточной работы средств
видеонаблюдения и пользователей Системы в режиме 24 часа в сутки 7 дней в неделю, включая
выходные и праздничные дни.
Система должна обеспечивать следующие режимы функционирования:
 штатный режим;
 сервисный режим;
 аварийный режим.
В штатном режиме все компоненты Системы выполняют свои функции, Система работает
в отказоустойчивом режиме, т.е. никакой единичный сбой или отказ технических средств не
может привести к частичной или полной потере функционала Системы или накопленных
данных архива видеоизображений.
Сервисный режим используется для выполнения операций подготовки и проведения
испытаний или настройки компонентов Системы. В данном режиме Системы или ее
подсистемы становятся недоступными для групп пользователей. В данном режиме
осуществляется
техническое
обслуживание,
реконфигурация,
модернизация
отдельных
подсистем и/или компонентов Системы.
Аварийный режим наступает, когда ввиду каких-либо факторов, прогнозируемых или нет,
происходит частичный и/или полный отказ технических средств или частичная потеря
функционала какой-либо подсистемы, приводящие к потере доступности предоставляемых
сервисов
и/или
создающие
производительность.
При
угрозу
этой
наступлении
доступности
предаварийного
и/или
или
понижающие
аварийного
общую
режимов
обслуживающий персонал должен предпринять необходимые действия для восстановления
функционирования неисправных компонентов Системы и возврата в штатный режим.
При разработке подсистем Системы необходимо учитывать возможность возникновения
следующих аварийных ситуаций:
 сбой общесистемного или специального ПО (отдельного АРМ или сервера);
 выход из строя технических средств и/или входящих в их состав компонентов;
 ошибки персонала при работе с Системы;
 сбои в электропитании.
4.1.1.4 Требования по диагностированию Системы
Все проектные решения должны учитывать
требование,
что
диагностирование
компонентов Системы осуществляется соответствующими подсистемами Системы путем
анализа записей в системных журналах программно-аппаратных средств и/или общесистемного
и прикладного ПО, а также с помощью встроенных средств диагностирования.
4.1.2
Требования к численности и квалификации персонала
Персонал Системы должен включать:
 пользователи – лица, которым предоставлен доступ к видеоинформации Системы
(далее – пользователи Системы);
 персонал, осуществляющий эксплуатацию Системы (далее – персонал Системы) сотрудники Оператора Системы или других организаций, обеспечивающие
эксплуатацию Системы в соответствие с установленными для них должностными
обязанностями. Состав, количество групп персонала, типы (роли) ответственности
и разграничения по ним определяются в рамках соответствующих регламентов.
Квалификация пользователей Системы должна позволять решать следующие задачи:
 осуществлять базовые функции работы с операционной системой;
 использовать прикладное клиентское ПО Системы в части выполнения своих
функциональных обязанностей.
Квалификация персонала Системы должна позволять решать следующие задачи:
 осуществлять
технологические
процессы,
связанные
с
регистрацией
пользователей и предоставлением им доступа к информации, обрабатываемой в
Системе;
 осуществлять технологические процессы, связанные с регистрацией средств
видеонаблюдения в Системе;
 осуществлять технологические процессы, связанные с администрированием и
управлением конфигурацией Системы;
 осуществлять технологические процессы, связанные резервным копированием и
восстановлением подсистем Системы;
 осуществлять
технологические
процессы,
связанные
с
управлением
информационной безопасностью Системы;
 осуществлять мониторинг и контроль работоспособности компонентов Системы.
Требования к квалификации персонала Системы и пользователей Системы должны быть
разработаны Исполнителем в составе Технорабочего проекта.
Персонал Системы должен пройти инструктаж и быть ознакомлен с эксплуатационной
документацией в объеме, необходимом для исполнения установленных должностных функций.
4.1.3
Показатели назначения
4.1.3.1 Общие требования
Для обновления подсистем Системы не должна требоваться остановка работы и/или
приведение подсистем к определенному состоянию с потерей накопленных видеоизображений
и/или информации в подсистеме ведения служебных реестров и справочников. Исключение, по
согласованию с Заказчиком, должны составлять только переход с одной версии программного
обеспечения на другую с возможностью сохранения данных служебных реестров и
справочников и накопленных видеоизображений.
Система должна допускать модернизацию, связанную с изменениями количественного и
качественного
состава
программно-аппаратных
средств,
операционного
окружения,
применением новых современных средств, методов и протоколов связи и передачи данных.
При разработке проектного решения должна быть предусмотрена возможность
последующего развития и модернизации Системы по следующим направлениям:
 расширение функциональных возможностей за счет дополнительной разработки
компонентов подсистем;
 расширение числа поставщиков информации в рамках разработанной технологии
информационного взаимодействия;
 увеличение
количества
пользователей,
при
своевременной
модернизации
вычислительных мощностей аппаратного обеспечения.
При
разработке
технического
решения
необходимо
предусмотреть
выполнение
следующих требований к архитектуре и технологическим возможностям системы, напрямую
влияющих на пределы модернизации и развития системы:
 использование открытых стандартов – прозрачность, адаптивность, широта
применения;
 доступность – обеспечение одинаково удобного доступа к ресурсам различным
категориям пользователей;
 модульность
–
структурирование
решения
на
функциональные
блоки,
отвечающие за выполнение отдельных задач с возможностью поэтапной
реализации;
 масштабируемость
–
возможность
увеличения
производительности
при
возрастании числа пользователей и объемов информационных потоков без
внесения кардинальных изменений в архитектуру и логику функционирования;
 функциональная адаптивность – возможность наращивания функциональных
возможностей без внесения кардинальных изменений в архитектуру и логику
функционирования системы.
4.1.3.2 Степень приспособляемости системы к изменению процессов и методов управления
Адаптация Системы при незначительных изменениях должна осуществляться путем
проведения структурной и параметрической настройки ее подсистем, а также за счет адаптации
информационного обеспечения и состава используемых информационных ресурсов.
4.1.3.3 Степень приспособляемости системы к отклонению параметров объекта
автоматизации
Система должна обеспечивать:
 масштабируемость по количеству пользователей до 50 000;
 масштабируемость
по
количеству
одновременно
транслируемых
видеоизображений до 100 000 (формат кодирования видеоданных H.264,
переменный или фиксированный поток данных до 2000 Кбит/с);
 масштабируемость по количеству одновременно транслируемых мгновенных
снимков (кадров) видеоизображений до 80 000 (мгновенные снимки с
разрешением не более 1920×1080);
 централизованное хранение и обработку служебных реестров и справочников;
 независимость от изменений в организационной структуре объектов внедрения
при сохранении состава и содержания выполняемых функций.
4.1.3.4 Допустимые пределы модернизации и развития системы
Система должна обеспечивать возможность модернизации и развития для повышения
степени приспособляемости при увеличении пределов изменений выше указанных параметров
объекта автоматизации, а также при изменении состава требований к выполняемым функциям и
видам обеспечения, за счет добавления программно-аппаратных средств и общесистемного
программного обеспечения, за счет конфигурирования параметров без изменения архитектуры
и необходимости перепрограммирования компонентов.
Система должна обеспечивать:
 масштабируемость по количеству пользователей до 1 000 000;
 масштабируемость
по
количеству
одновременно
транслируемых
видеоизображений до 1 000 000 (формат кодирования видеоданных H.264,
переменный или фиксированный поток данных до 2000 Кбит/с);
 масштабируемость по количеству одновременно транслируемых мгновенных
снимков (кадров) видеоизображений до 1000 000 (мгновенные снимки с
разрешением не более 1920×1080).
 централизованное хранение и обработку служебных реестров и справочников;
 независимость от изменений в организационной структуре объектов внедрения
при сохранении состава и содержания выполняемых функций.
Модернизация и развитие Системы должны проводиться специалистами Оператора
Системы и/или специалистами других организаций, обладающими необходимыми знаниями
предметной
области
с
помощью
соответствующего
программного
обеспечения,
автоматизирующего процесс модернизации и развития.
По итогам модернизации должен быть составлен протокол с полученными результатами.
4.1.3.5 Вероятностно-временные характеристики, при которых сохраняется целевое
назначение системы
Целевое назначение Системы должно сохраняться в течение 10 лет.
Требования к надежности
4.1.4
Надежность Системы в целом определяется надежностью функционирования ее
компонентов, а также надежностью обеспечивающих технических и программных средств.
Система должна обладать надежностью, обеспечивающей круглосуточную работу и
оперативное восстановление работоспособности общесистемного и специального ПО при
сбоях.
Требования к надежности Системы устанавливаются для системы в целом и ее составных
частей.
Общими требованиями по обеспечению надежности Системы являются:
 Система в целом должна сохранять работоспособность при некорректных
действиях конечных пользователей и предусматривать возможность оперативного
восстановления функционирования и исправления последствий подобных
действий при соблюдении требований эксплуатационной документации;
 Система должна обеспечивать восстановление работоспособности при появлении
единичных сбоев, аварий и отказов, возникающих на программно-технических
средствах;
 Система не должна терять работоспособность в случае возникновения сбоев,
аварий и отказов, возникающих на АРМ пользователей;
 Система должна обеспечивать сохранность данных при сбоях в электропитании
программно-аппаратных средств системы и АРМ пользователей.
Для обеспечения надежности должны применяться следующие меры:
 выбор
надежных
компонентами;
программно-аппаратных
средств
с
резервируемыми
 размещение оборудования Системы (за исключением АРМ) в помещениях,
оборудованных автоматическими системами противопожарной сигнализации,
пожаротушения и кондиционирования;
 организация резервных мощностей для горячего и холодного резервирования
информационных систем и сервисов Системы;
 резервное копирование служебной информации в соответствие с регламентами
резервного
копирования
и
периодическое
тестирование
процедуры
восстановления данных из резервных копий;
 система
должна
поддерживать
дублирование
архивной
информации
по
требованиям спец. заказчика.
 система должна поддерживать организацию регламентированного доступа к
ресурсам Системы;
 система должна вести журнал доступа и действий персонала ко всем элементам
системы;
 строгое соблюдение условий эксплуатации;
 другие технические, организационные и административные мероприятия.
Системы должна удовлетворять следующие количественные показателям надежности:
 обеспечить режим работы– 24/7;
 допустимое максимальное время начала работ по устранению неисправности и
восстановлению работоспособности персоналом Оператора Системы не должно
превышать сроки, определенные регламентом. В это значение входят все
необходимые работы по восстановлению работоспособности компонентов
Системы, за исключением решения проблем с техническим обеспечением.
4.1.5
Требования по безопасности программно-аппаратных средств системы
Программно-аппаратные
средства
Системы
должны
обеспечивать
безопасность
обслуживающего персонала при эксплуатации, техническом обслуживании и ремонте с учетом
требований ГОСТ 21552-84, ГОСТ 25861-83.
Электробезопасность должна соответствовать требованиям ГОСТ 12.1.030-81, ГОСТ
12.2.003, ГОСТ 12.2.007.0-75.
Силовые кабельные комплекса технических средств системы должны отвечать
требованиям «Правил устройств электроустановок» (ПУЭ).
Технические
стандартов
средства
безопасности
должны
труда
электромагнитной безопасности.
и
отвечать
иметь
действующей
сертификаты
по
системе
государственных
электробезопасности
и
4.1.6
Требования к эргономике и технической эстетике
Экранные формы, меню, шрифты, а также другие элементы оформления должны быть
подобранны с учетом продолжительной работы пользователя и должны способствовать
повышению эффективности работы пользователей с информационными ресурсами.
Все обозначения, названия элементов, классификаторы должны быть изложены на
русском языке без применения терминов, непонятных целевой аудитории.
Применяемые технические средства должны иметь возможность установки в 19”
телекоммуникационные монтажные шкафы. В том случае, если применяемое техническое
решение подразумевает использование оборудования, не предназначенного для установки в 19дюймовые серверные стойки, такое оборудование должно иметь моноблочное исполнение в
корпусе напольной конструкции со встроенной системой вентиляции и контроля температуры.
Размещение технических средств в коммуникационных и серверных стойках должно быть
оптимизировано с учётом минимизации трасс кабельных каналов, расположения ИБП, удобства
сопровождения и обслуживания. В местах размещения компонентов подсистем Системы,
связанных
с
использованием
кабельных
соединений,
должны
быть
предусмотрены
конструктивные элементы для укладки кабеля (кабельные органайзеры, кольца и пр.).
При проведении пуско-наладочных работ должна быть выполнена маркировка каждого
компонента, обеспечивающая однозначную идентификацию компонентов в соответствие с
эксплуатационной документацией.
4.1.7
Требования к эксплуатации, техническому обслуживанию, ремонту и хранению
компонентов системы
Система должна обеспечивать работу в режиме 24/7. Последовательность действий и
процедур по организации обслуживания и эксплуатации Системы, включая процессы
поддержки пользователей, должны быть разработаны Исполнителем.
С целью поддержания работоспособности системы, Оператор Системы должен
обеспечить:
 обработку заявок, поступающих из диспетчерского центра;
 администрирование Системы;
 конфигурирование программно-аппаратных средств и программного обеспечения
Системы;
 соответствие Системы требованиям безопасности информации;
 диагностику программно-технических средств Системы;
 решение проблем функционирования программно-технических средств Системы;
 проактивный и оперативный мониторинг функционирования программнотехнических средств и программного обеспечения Системы;
 проведение профилактического и регламентного обслуживания программнотехнических средств и программного обеспечения Системы;
 обновление программного обеспечения;
 восстановление работоспособности программно-аппаратных средств при выходе
их из строя;
 замену
неисправных
компонентов
программно-аппаратных
средств
на
идентичные или удовлетворяющие требованиям технической документации на
систему;
 управление производительностью функционирования Системы;
 проведение ремонта программно-технических средств Системы.
Перечень
и
регулярность
мероприятий
по
проведению
профилактического
и
регламентного обслуживания компонентов Системы определяется, по согласованию с
Заказчиком, внутренними распоряжениями и/или решениями Оператора Системы, с учетом
рекомендаций
производителей
программно-аппаратных
средств,
условий
эксплуатации
Системы и результатам анализа показателей подсистемы мониторинга программно-аппаратных
средств.
Оператор
Системы
обеспечивает
наличие
подменного
фонда
запасных
частей,
инструментов и принадлежностей (ЗИП) на ключевые элементы программно-аппаратных и
технических
средств
Системы,
в
соответствие
с
требованиями
по
обеспечению
отказоустойчивости и доступности компонентов Системы и результатам анализа показателей
подсистемы мониторинга программно-аппаратных средств.
Для обеспечения целостности данных Системы необходимо производить периодическое
резервное копирование служебных БД. Резервное копирование и восстановление должно
производиться средствами подсистемы резервного копирования и восстановления данных.
Выполнение процедур копирования и восстановления данных должно выполняться
персоналом Системы. Частота и регулярность периодического резервирования и копирования
данных определяется, по согласованию с Заказчиком, внутренними распоряжениями и /или
решениями Оператора Системы.
4.1.8
Требования к обеспечению безопасности информации
Для обеспечения защиты данных, хранящихся и обрабатываемых Системы необходимо
определить и соответствующим образом описать объекты данных, с которыми работает
система, классифицировать данные в соответствии с законодательством РФ, а так же уровнем
конфиденциальности данных, предъявляемым заказчиком.
Технические решения по созданию подсистем Системы и организационные меры должны
обеспечивать целостность видеоизображений, хранимых в Системы.
4.1.9
Требования по сохранности информации при авариях
Сохранность информации при сбоях и авариях должна достигаться за счет архитектуры
построения технических средств и программного обеспечения Системы.
На случай необратимой потери данных подсистема резервного копирования и
восстановления данных должна обеспечивать резервирование системного и специального ПО
для оперативного восстановления функционирования компонентов Системы.
Резервирование видеоизображений, размещенных в Системе, должно осуществляться за
счет избыточности компонентов подсистемы хранения данных и обеспечивать сохранность
видеоизображений при любом однократном выходе из строя компонентов подсистемы
хранения.
Обеспечение сохранности информации при авариях должно достигаться следующими
методами:
 в рамках проектирования должны быть разработаны меры, направленные на
выполнение требований к показателям надежности;
 неукоснительно
соблюдаться
условия
эксплуатации,
установленные
в
технической и эксплуатационной документации соответствующих технических и
программных средств информационной системы;
 выполняться требования к Системе в части технического обслуживания
технических и программных средств;
 выполняться
требования
к
управлению
Системой
в
части
контроля
функционирования и анализа технических неисправностей.
4.1.10 Требования к защите от влияния внешних воздействий
Защита Системы от влияния внешних воздействий должна осуществляться в рамках
общих организационно-технических мероприятий по обеспечению безопасности и физической
защиты на объектах внедрения Системы. В рамках проектирования должны быть разработаны
перечень и состав организационно-технических мероприятий.
Для защиты от влияния внешних воздействий при создании Системы должны
учитываться:
 требования к радиоэлектронной защите технических средств автоматизированных
систем согласно ГОСТ 19542–83 «Совместимость средств вычислительной
техники электромагнитная. Термины и определения», ГОСТ Р 50628–2000
«Совместимость
машин
электронных
вычислительных
персональных
электромагнитная. Устойчивость к электромагнитным помехам. Технические
требования и методы испытаний»;
 требования по стойкости, устойчивости и прочности к внешним воздействиям для
технических средств Системы определяются согласно ГОСТ 27201–87 «Машины
вычислительные электронные персональные. Типы, основные параметры, общие
технические требования».
4.1.11 Требования к патентной чистоте
Патентная чистота Системы и ее частей должна быть обеспечена в отношении патентов,
действующих на территории Российской Федерации.
Реализация
технических,
программных,
организационных
и
иных
решений,
предусмотренных проектом системы не должна приводить к нарушению авторских и смежных
прав третьих лиц.
При использовании в системе программ (программных комплексов или компонентов),
разработанных третьими лицами, условия, на которых передается право на использование
(исполнение) этих программ, не должны накладывать ограничений, препятствующих
использованию системы по ее прямому назначению.
4.1.12 Требования к стандартизации и унификации
Проводимые работы должны соответствовать следующим требованиям:
 применяемые при создании Системы технические (форматы данных, протоколы
передачи и прочие) и организационные (регламенты, требования, инструкции и
т.п.) решения должны быть доступны и документированы в виде, достаточном для
независимой реализации третьими сторонами. Применение недокументированных
или недоступных решений не допускается;
 при выборе применяемых решений преимущество должно отдаваться решениям,
основанным на стандартизированных технологиях, т.е. прошедшим процедуру
стандартизации и утвержденным в качестве стандарта либо рекомендации какимлибо признанным международным, федеральным, отраслевым, промышленным
органом по стандартизации;
 проектные решения разрабатываемой системы при выполнении различных
функций системы должны обеспечивать:

соблюдение единых правил организации интерфейса с пользователем;

единообразную реакцию компонентов системы на неверные действия
пользователей;

использование фиксированного перечня терминов и определений системы
при организации диалога и формировании экранов;

типовой подход к разграничению прав доступа пользователей к информации
системы;

должно быть предусмотрено использование единой системы справочников.
Все разработанное прикладное программное обеспечение должно передаваться Заказчику
вместе с исходными кодами.
Экранные формы пользовательского интерфейса должны проектироваться с учетом
требований унификации, представленных в Разделе 4.1.6 «Требования к эргономике и
технической эстетике».
4.2 Требования к функциям (задачам), выполняемым Системой
4.2.1
Требования к вычислительной подсистеме
o
4.2.2
Требования к подсистеме хранения данных
Подсистема
хранения данных
должна
обеспечивать
следующий
функционал
и
технические характеристики:
4.2.3
Требования к подсистеме сети передачи данных
Подсистема сети передачи данных должна быть основана на использовании отраслевых
стандартов,
обеспечивать
взаимодействие
с
другим
оборудованием
по
стандартным
протоколам.
Подсистема сети передачи данных должна обеспечивать следующий функционал и
технические характеристики:
o
4.2.4
Требования к подсистеме виртуализации
Подсистема виртуализации должна обеспечивать следующий функционал:
 обеспечивать
виртуализацию
типа
"bare-metal",
то
есть
устанавливаться
непосредственно на сервер без операционной системы.
 ПО среды виртуализации должно иметь лицензию на каждое процессорное гнездо
всех используемых серверов в блоке вычислительной инфраструктуры.
 иметь ограничение в не менее чем 25 виртуальных процессоров на одно ядро
процессора блейд-сервера.
 обеспечивать
работу
виртуальных
машин
под
управлением
следующих
операционных систем:
o Windows Server 2008.
o Windows 7
o Windows Vista.
o Windows Server 2003.
o Windows XP.
o Windows 2000.
o Windows NT 4.0.
o Red Hat Enterprise Linux.
o SUSE Linux Enterprise Server.
o Ubuntu Linux.
 поддерживать 32- и 64-битные системы и симметричную мультипроцессорную
обработку (несколько виртуальных процессоров виртуальных машин).
 иметь возможность предоставления гипервизором всех физических процессоров и
процессорных ядер серверов для работы виртуальных машин.
 иметь возможность создания виртуальных машин с не менее чем 32
виртуальными
процессорами
для
Windows-систем
и
возможностью
использования не менее 1 ТБ оперативной памяти внутри виртуальной машины.
 предоставлять возможность создания виртуальных машин с различными
конфигурациями виртуальных аппаратных средств (количество процессоров,
памяти, типы контроллеров и дисков, количество сетевых карт, дополнительные
периферийные устройства), а также предоставить возможность динамического
изменения их конфигурации.
 обеспечивать
разделение
сетевых
ресурсов
виртуальных
машин
и
ПО
гипервизора. При работе с сетью виртуальные машины, работающие на сервере,
не должны влиять на доступность сервера виртуализации в целом.
 обеспечивать изоляцию виртуальных машин. Повышенная загруженность или
сбои программного обеспечения внутри одной виртуальной машин не должны
влиять на доступность и производительность других виртуальных машин,
работающих на этом же физическом сервере.
 предоставлять возможность создания кластера высокой доступности для
обеспечения отказоустойчивости системы в целом и реализации бесперебойной
работы виртуальных машин.
 обеспечивать автоматический перенос нагрузки на другой сервер или перезапуск
виртуальных машин при выходе из строя сервера виртуализации, а также
реализовывать политики, предоставляющие избыточные ресурсы, прежде всего,
для критически важных виртуальных машин. Время простоя при отказе сервера и
автоматическом перезапуске системы на другом сервере, не должно превышать 10
минут.
 обеспечивать перемещение одновременно до двух виртуальных машин между
серверами и/или хранилищ без остановки их работы («горячая миграция»). Также
должен быть предусмотрен способ «холодной миграции» виртуальных машин
между серверами, обеспечивающий минимальное время простоя.
 обеспечивать балансировку нагрузки на устройства как сетей передачи данных
(NIC Teaming / Bonding), так и сетей хранения данных.
 обеспечивать отказоустойчивый доступ виртуальных машин,
как к сетям
передачи данных, так и к сетям хранения данных.
 предоставлять возможность централизованного управления всеми ключевыми
компонентами среды виртуализации и иметь отказоустойчивую конфигурацию.
 обеспечивать возможность работы нескольких администраторов одновременно.
 средства управления должны предоставлять все необходимое для удаленного
конфигурирования серверов виртуализации и автоматизации процедур и
рутинных задач управления через уведомления и планирование заданий, иметь
средства мониторинга доступности и загрузки ресурсов;
 обеспечивать
защиту
от
несанкционированного
доступа,
включающую
регистрацию, учет и управление доступом, протоколирование событий.
 иметь поддержку производителя не менее 3-х лет.
4.2.5
Требования к подсистеме базовых инфраструктурных сервисов
Подсистема базовых инфраструктурных сервисов должна обеспечивать следующий
функционал:
 функционировать на ресурсах, предоставляемых подсистемой виртуализации;
 использовать операционную систему, обеспечивающую:
o поддержку Intel совместимых процессоров x64;
o поддержку до 4-х физических процессоров;
o поддержку до 32 ГБ оперативной памяти;
o поддержку
основными
производителями
компьютерных
комплектующих
и
периферийных устройств в виде разработки драйверов устройств; o встроенные
инструменты мониторинга и журналы событий;
o интерфейс пользователя на английском или русском языках, в зависимости от
инсталляции;
o встроенные возможности доступа к удаленному столу пользователя по сети;
o встроенные
возможность
централизованной
настройки
параметров
пользовательского окружения и параметров безопасности для всех рабочих станций
в управляемой сетевой инфраструктуре;
o встроенную поддержку функции единого входа в систему в управляемой сетевой
инфраструктуре;
o поддержку возможности централизованного развертывания образов настроенной
операционной системы на серверы по сети;
o встроенный межсетевой экран, с возможностью централизованного управления в
управляемой сетевой инфраструктуре;
 предоставлять
следующие
инфраструктурные
сервисы,
необходимые
для
функционирования Системы:
 Domain Name System Server;
 сетевые файловые сервисы с возможностью организации распределенных
файловых сервисов и репликации по сети;
 служба аутентификации RADIUS;
 служба каталогов;
 предоставлять сервис управления базами, необходимый для функционирования
Системы:
o включать функционал передачи данных в распределенных сетях;
o иметь возможность извлечения, преобразования и загрузки для хранилищ данных и
интеграции данных в масштабе предприятия;
o включать инструменты аналитической обработка в реальном времени (OLAP) для
быстрого, сложного анализа больших и смешанных наборов данных, использующая
многомерное хранение;
o включать инструменты для создания и управления отчетами;
o инструменты управления - должны включать средства управления для развитого
управления и настройки баз данных. Должна поддерживаться тесная интеграция с
такими
инструментами,
как
системы
мониторинга
производительности
и
доступности сервисов, системы управления и удаленной инсталляции приложений,
порталы, системы управления проектами и коммуникационные системы;
o должна поддерживать возможность интеграции с СУБД других производителей для
изъятия данных и их обработки и анализа. Должна обеспечиваться возможность
получения данных из электронных таблиц Excel;
o должна
поддерживаться
возможность
интеграции
с
источниками
геоинформационных данных и использование этих данных при анализе;
o инструменты разработки - должны включаться интегрированные инструменты
разработки для ядра базы данных, извлечения, трансформации и загрузки данных,
извлечения информации, OLAP и отчётности, которые тесно должна быть
обеспечена совместимость с технологией dotNET для предоставления сквозных
возможностей разработки приложений;
o должна обеспечиваться возможность построения кластера серверов СУБД с числом
узлов не менее двух;
o поддержка не менее 16 физических или виртуальных ядер на сервере;
o должна обеспечиваться возможность создания дополнительных копий баз данных на
другом сервере с возможностью доступа к данным в режиме чтения. Не должно
требоваться приобретения дополнительных лицензий для пассивного узла кластера;
o каждая лицензия на ПО должна предоставлять возможность использования до двух
ядер центрального процессора или одного виртуального процессора.
4.2.6
Требования к подсистеме резервного копирования и восстановления данных
Подсистема резервного копирования должна обеспечивать:
 резервирование виртуальных машин под управлением операционной системы как
Linux, так и Windows;
 резервирование
СУБД,
используемой
в
составе
подсистемы
базовых
инфраструктурных сервисов;
 копирование данных на жесткие диски;
 возможность дедупликации данных.
4.2.7
Требования к подсистеме базовых функций видеонаблюдения
Подсистема базовых функций видеонаблюдения должна основываться на модульном
принципе построения, с соблюдением уровней иерархии и разграничением выполняемых
функций:
 модуль аутентификации и авторизации пользователей;
 модуль назначения приоритетов и полномочий;
 модуль управления приоритетами и полномочиями.
Все приоритеты и полномочия должны предоставляться пользователю только в случае
явного наличия данных полномочий на данное средство видеонаблюдения.
Модуль аутентификации и авторизации пользователей должен обеспечивать:
 возможность идентификации и аутентификации пользователя;
 возможность предоставления пользователю доступа к Системе только после
предъявления уникального персонифицированного идентификатора (имени)
пользователя и проведения процедуры аутентификации на основе учетной записи
и пароля пользователя, с возможностью поддержки процедуры аутентификации
по цифровому сертификату и ключевому носителю;
 взаимодействие с подсистемой протоколирования действий пользователя для
регистрации действий пользователя;
 возможность определения авторства определенных действий пользователя в
Системе и отсутствие неавторизованных действий на основе уникальных
персонифицированных идентификаторов каждого пользователя, процедуры
аутентификации и протоколирования действий пользователей;
 наличие развитой системы управления аутентификационной информацией
пользователей и механизмов контроля за ее качеством и использованием,
обладающей следующими характеристиками:
o возможность установки администратором минимальной длины пароля;
o возможность установки администратором признака периодической принудительной
смены паролей для пользователей;
o возможность установки администратором признака принудительной смены пароля
пользователя при следующем подключении пользователя к Системе;
o возможность самостоятельного изменения пользователями своего пароля в любое
время;
o автоматическая
установка
новому
пользователю
пароля,
задаваемого
администратором Системы;
o предоставление доступа к информации при первом подключении пользователя к
Системе только после смены им пароля, установленного администратором, на его
личный пароль;
o хранение парольной «истории» пользователя, т.е. списка контрольных значений
(сумм) нескольких предыдущих паролей пользователя (количество предыдущих
паролей должно устанавливаться администратором), и невозможность при смене
пароля выбора пароля из этого списка;
o выполнение анализа качества выбираемых пользователями паролей по заданным
критериям;
o при вводе пароля пользователем на запрос Системы символы пароля на экране не
отображаются (отображается только число введенных символов);
 передачу аутентификационной информации по каналу связи от клиента серверу
без возможности восстановления пароля пользователя (кроме как методом
полного перебора) по перехваченной в канале связи информации;
 предоставление веб-интерфейса для конфигурирования параметров модуля;
 предоставление веб-интерфейса пользователем для ввода аутентификационной
информации;
 поддержку
динамического
взаимодействия
с
внешней
системой
через
реализуемый API.
Модуль назначения приоритетов и полномочий должен обеспечивать:
 горизонтальное масштабирование компонентов при добавлении программноаппаратных средств, за счет конфигурирования параметров без изменения
архитектуры и необходимости перепрограммирования модуля;
 поддержку следующих объектов:
o пользователь;
o группа пользователей;
o полномочие;
o группа полномочий;
o уровень приоритета пользователя;
o средство видеонаблюдения;
o группа средств видеонаблюдения.
 уникальность объекта в рамках Системы;
 возможность создания групп типизированных объектов;
 поддержка вложенных групп типизированных объектов;
 возможность делегирования пользователю прав управления полномочиями;
 поддержку следующих приоритетов пользователей:
o перехват управления средствами видеонаблюдения, оснащенными поворотными
устройствами;
o отключение возможности управления и просмотра изображения со средств
видеонаблюдения (функция блокировки средств видеонаблюдения и видеопотоков и
прекращения к ним доступа пользователей Системы с более низким приоритетом);
 поддержку следующих полномочий пользователя:
o просмотр видеопотока с определенного перечня средств видеонаблюдения;
o просмотр
архива
видеоизображений
с
определенного
перечня
средств
видеонаблюдения;
o использование функций PTZ-управления средством видеонаблюдения;
o блокировка функций PTZ-управления средством видеонаблюдения;
o блокировка видеопотока;
o использование
команд
управления
дополнительными
функциями
средства
видеонаблюдения (ИК-подсветка, обогрев купола и др.);
o создание мгновенного снимка (кадра) и его сохранение на АРМ пользователя;
o изменение регистрационных сведений пользователя;
o изменение состава полномочий пользователя;
 предоставление
веб-интерфейса
для
конфигурирования
приоритетов
и
полномочий пользователя;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
Модуль управления приоритетами и полномочиями должен обеспечивать:
 горизонтальное масштабирование компонентов при добавлении программноаппаратных средств, за счет конфигурирования параметров без изменения
архитектуры и необходимости перепрограммирования модуля;
 динамическое
применение
назначенных
приоритетов
и
полномочий
для
пользователей Системы;
 принудительное изменение настроек клиентского ПО в случае:
o изменения состава назначенных полномочий;
o изменения статуса средства видеонаблюдения;
o блокировки управления средством видеонаблюдения;
o блокировки видеопотока другими пользователями;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
4.2.8
Требования к подсистеме обработки видеоизображений
Подсистема обработки и трансляции видеоизображений должна основываться на
модульном принципе построения, с соблюдением уровней иерархии и разграничением
выполняемых функций:
 модуль получения и предоставления видеоизображений;
 модуль управления средствами видеонаблюдения.
Модуль получения и предоставления видеоизображений должен обеспечивать:
 горизонтальное масштабирование компонентов при добавлении программноаппаратных средств, за счет конфигурирования параметров без изменения
архитектуры и необходимости перепрограммирования модуля;
 автоматизированное перераспределение функций при отказе компонентов;
 поддержку формата кодирования видеопотоков H.264;
 получение видеопотоков с устройств, работающих в стандартах PAL и NTSC;
 получение видеопотоков реального времени с устройств по протоколам
RTSP/RTMP;
 программные интерфейсы для интеграции модулей получения видеопотоков
реального времени с устройств, предоставляющих проприетарные протоколы,
отличные от RTSP/RTMP;
 ретрансляцию потокового видео в формате H.264 для выдачи видеоизображений
по определенным протоколам доступа для последующего воспроизведения на
Android и iOS устройствах;
 возможность принудительного блокирования и/или разблокирования трансляции
видеопотока;
 возможность удаленного конфигурирования компонентов со стороны модуля
конфигурирования и мониторинга видеопотоков на основе веб-сервисов в объеме
функций:
o добавление статического URL-видеопотока для трансляции реального времени;
o добавление статического URL-видеопотока для трансляции архива;
o запрос динамического URL для трансляции реального времени;
o запрос динамического URL для трансляции архива;
o удаление видеопотока.
 автоматизированное выявление неисправностей, связанных:
o с недоступностью компонентов модуля;
o с недоступностью средства видеонаблюдения;
o с недоступностью видеопотока;
o с существенным ухудшением качества видеоизображений, в т.ч. превышением
заданного количества потерянных пакетов видеопотоке;
o с формированием архива видеоизображений;
 формирование
оповещений
о
состоянии
компонентов
модуля,
средств
видеонаблюдения и качества видеопотоков;
 возможность
использования
централизованных
шаблонов
для
настройки
компонентов;
 предоставление веб-интерфейса для конфигурирования компонентов модуля;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
Модуль управления средствами видеонаблюдения должен обеспечивать:
 горизонтальное масштабирование компонентов при добавлении программноаппаратных средств, за счет конфигурирования параметров без изменения
архитектуры и необходимости перепрограммирования модуля;
 отказоустойчивое функционирование и автоматизированное перераспределение
функций при отказе компонентов;
 возможность
выполнения
функций
PTZ-управления
средствами
видеонаблюдения;1
 возможность использования команд управления дополнительными функциями
средства видеонаблюдения (ИК-подсветка, обогрев купола и др.)2;
 удаленную настройку конфигурационных параметров средств видеонаблюдения,
на основе сведений подсистемы ведения служебных реестров и справочников, и
их автоматическое применение;3
 возможность
автоматизированного
формирования
перечня
средств
видеонаблюдения, подключаемых к Системе, на основе сведений подсистемы
ведения служебных реестров и справочников, и их автоматическое распределение
по компонентам модуля получения и предоставления видеоизображений в
зависимости от текущей нагрузки компонентов;
В случае, если вызовы данных функций могут реализованы с помощью внешних вызовов API управления средства
видеонаблюдения. API на средство видеонаблюдения должно быть доступно на сайте производителя оборудования
или должно предоставляться Заказчиком для изучения специалистами Исполнителя.
2
В случае, если вызовы данных функций могут реализованы с помощью внешних вызовов API управления средства
видеонаблюдения. API на средство видеонаблюдения должно быть доступно на сайте производителя оборудования
или должно предоставляться Заказчиком для изучения специалистами Исполнителя.
3
В случае, если такая возможность может быть реализована с помощью внешних вызовов API управления средства
видеонаблюдения. API на средство видеонаблюдения должно быть доступно на сайте производителя оборудования
или должно предоставляться Заказчиком для изучения специалистами Исполнителя.
1
 возможность
использования
централизованных
шаблонов
для
настройки
компонентов модуля;
 предоставление веб-интерфейса для конфигурирования компонентов модуля,
мониторинга текущего состояния и получения отчетности;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
4.2.9
Требования к подсистеме ведения архива
Подсистема ведения архива должна обеспечивать:
 циклическое формирование архива видеоизображений и мгновенных снимков
(кадров) видеоизображений в локальные хранилища с управляемой глубиной
хранения, задаваемой по времени4;
 предоставление видеопотоков и мгновенных снимков видеоизображений из
архива видеоизображений;
 предоставление веб-интерфейса для конфигурирования компонентов модуля,
мониторинга текущего состояния и получения отчетности;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
4.2.10 Требования к подсистеме трансляции видеоизображений
Подсистема трансляции видеоизображений должна обеспечивать:
 горизонтальное масштабирование компонентов при добавлении программноаппаратных средств, за счет конфигурирования параметров без изменения
архитектуры и необходимости перепрограммирования модуля;
 автоматизированное перераспределение функций при отказе компонентов;
 автоматическое определение параметров клиентского ПО и предоставление
видеопотоков в требуемом формате;
 предоставление видеопотоков по протоколу RTMP / HLS / RTSP;
 предоставление мгновенных снимков (кадров) видеоизображений;
 отсутствие дублированных видеопотоков со стороны подсистемы
обработки
видеоизображений;
 предоставление веб-интерфейса для конфигурирования компонентов модуля;
Глубина архива определяется возможностями локального хранилища, количеством средств видеонаблюдения и
параметрами видеопотока.
4
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
4.2.11 Требования к подсистеме протоколирования
Подсистема протоколирования действий пользователя предназначена для анализа
активности пользователей в реальном масштабе времени, мониторинга и протоколирования
определенных действий пользователей, отслеживания правомерности этих действий и
повышения контроля доступа пользователей к архиву видеоизображений.
Подсистема протоколирования действий пользователя должна обеспечивать:
 запись идентификационной информации о событии в журнале событий:
o уровень события;
o дата наступления события;
o время наступления события;
o источник события;
o код события;
o краткое описание события;
o подробности события;
 классификацию событий, в зависимости от степени влияния на технологические
процессы и/или функциональные возможности Системы, по следующим уровням:
o сведения;
o предупреждение;
o ошибка;
 запись
идентификационной
информации
о
следующих
действиях,
осуществляемых пользователем:
o просмотр видеопотока;
o использование функций PTZ-управления средством видеонаблюдения;
o изменение пользователем режимов работы средства видеонаблюдения;
o создание мгновенного снимка (кадра) видеопотока и его сохранение на АРМ
пользователя;
o блокировка функций PTZ-управления средством видеонаблюдения;
o блокировка видеопотока;
o просмотр архива видеоизображений;
o изменение приоритета и состава полномочий пользователя;
o изменение регистрационных сведений в подсистеме ведения служебных реестров и
справочников;
o доступ к журналу событий;
 предоставление веб-интерфейса для просмотра и управления журналом событий;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
4.2.12 Требования к подсистеме мониторинга видеоизображений
Подсистема мониторинга видеоизображений должна обеспечивать:
 формирование оперативной информации по текущему состоянию средств
видеонаблюдения:
o доступность/недоступность средства видеонаблюдения;
o доступность/недоступность видеопотока;
o качество видеопотока;
o состояние записи архива видеоизображений;
 формирование и предоставление статистической отчетности по количеству
подключенных к Системе средств видеонаблюдения и качеству предоставляемых
видеопотоков за настраиваемый период:
o список подключенных средств видеонаблюдения с указанием текущего статуса
качества получаемых видеопотоков;
o статистику по используемому дисковому пространству для хранения архивов
видеоизображений;
o период доступности/недоступности средства видеонаблюдения;
o период доступности/недоступности видеопотока;
o количество потерянных пакетов за период;
o состояние записи архива видеоизображений за период.
 предоставление веб-интерфейса для просмотра оперативного состояния средств
видеонаблюдения и видеопотоков, статистической отчетности;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
4.2.13 Требования к подсистеме интеграции
Подсистема интеграции с внешними ИС должна обеспечивать:
 горизонтальное масштабирование компонентов при добавлении программноаппаратных средств, за счет конфигурирования параметров без изменения
архитектуры и необходимости перепрограммирования;
 предоставление веб-интерфейса для тестирования функций взаимодействия;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API:
o получение сведений из подсистемы ведения служебных реестров и справочников;
o получение фильтрованного реестра средств видеонаблюдения:
 фильтрация по типам средств видеонаблюдения;
 фильтрация по статусам средств видеонаблюдения;
 фильтрация по наименованию средств видеонаблюдения;
 фильтрация средств видеонаблюдения по адресу размещения;
o поддержка постраничного вывода списков средств видеонаблюдения;
o получение сведений из подсистемы ведения служебных реестров и справочников с
адресами трансляций с фильтром по протоколу трансляции;
o получение даты последних изменений настраиваемых параметров из подсистемы
ведения служебных реестров и справочников;
o предоставление статусов средств видеонаблюдения;
o предоставление видеопотоков с определенного средства видеонаблюдения;
o предоставление мгновенных снимков (кадров) видеоизображений с определенного
средства видеонаблюдения.
4.2.14 Требования к подсистеме ведения служебных реестров и справочников
Подсистема ведения служебных реестров и справочников должна основываться на
модульном принципе построения, с соблюдением уровней иерархии и разграничением
выполняемых функций:
 модуль ведения Реестра пользователей;
 модуль ведения Реестра средств видеонаблюдения;
 модуль ведения служебных справочников и классификаторов.
Модуль ведения Реестра пользователей Системы должен обеспечивать:
 централизованное хранение и обработку ведение регистрационных сведений
пользователей, которым предоставлен доступ к Системе;
 уникальность объектов, хранимых в Реестре пользователей;
 хранение истории изменений объектов, хранимых в Реестре пользователей;
 ведение регистрационных сведений организаций, которым предоставлен доступ к
Системе;
 сопровождение следующих технологических процессов:
o внесение регистрационных сведений пользователя в Реестр пользователей;
o внесение изменений в состав полномочий пользователя;
o исключение пользователя из Реестра пользователей;
 предоставление веб-интерфейса для создания и внесения изменений в Реестр
пользователей;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
Модуль ведения Реестра средств видеонаблюдения должен обеспечивать:
 централизованное хранение и обработку регистрационных сведений средств
видеонаблюдения;
 уникальность объектов, хранимых в Реестре средств видеонаблюдения;
 хранение
истории
изменений
объектов,
хранимых
в
Реестре
средств
видеонаблюдения;
 изменение режимов работы средств видеонаблюдения:
o «регистрация»;
o «эксплуатация»;
o «неисправность»;
o «жалоба пользователя»;
o «техническое обслуживание»;
 сопровождение следующих технологических процессов:
o внесение регистрационных сведений средства видеонаблюдения в Реестр средств
видеонаблюдения;
o согласование регистрационных сведений средства видеонаблюдения;
o изменение режимов эксплуатация средства видеонаблюдения;
o исключение средства видеонаблюдения из Реестра средств видеонаблюдения.
 предоставление веб-интерфейса для создания и внесения изменений в Реестр
средств видеонаблюдения;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
Модуль ведения служебных справочников и классификаторов должен обеспечивать.
 уникальность объектов, хранимых в служебных справочниках и классификаторах;
 хранение истории изменений объектов, хранимых в служебных справочниках и
классификаторах;
 предоставление веб-интерфейса для создания и внесения изменений в служебные
справочники и классификаторы;
 поддержку взаимодействия с другими компонентами Системы через реализуемый
API.
4.2.15 Требования к подсистеме видеоаналитических модулей (детекторов)
Подсистема видеоаналитических модулей должна основываться на модульном принципе
построения и включать в себя:
4.2.15.1 Детектор движения
Детектор движения предназначен для решения базовой задачи выявления движущихся объектов.
Предназначен для решения ряда функциональных задач по выявлению проникновения. Детектор
обеспечивает:
 определение появившихся объектов в контрольной зоне
 детекцию и трекинг движущихся объектов (людей) в кадре (сцене);
 фильтрацию результатов детекции в соответствии с заранее заданными границами
контрольной зоны;
 формирование сообщения, содержащего информацию о детектированном объекте,
включая дату и точное время детекции,
 формирование и отправку в Подсистему обмена событиями (ПОС) кадра (изображения)
в формате JPEG или PNG,
 старт записи события в архив системы видеонаблюдения.
4.2.15.2 Детектор оставленных предметов
Детектор оставленных предметов предназначен для решения базовой задачи выявления
неподвижных появившихся или исчезнувших объектов, а также является компонентом решений
ряда функциональных задач, включая определение нарушения правил парковки.
Детектор оставленных предметов обеспечивает:

определение оставленных (появившихся) или исчезнувших предметов в кадре (сцене);

фильтрацию результатов детекции в соответствии с заранее заданными размерами объекта
(с учетом перспективных искажений) и границами контрольной зоны;

формирование сообщения, содержащего информацию о детектированном объекте, включая
дату и точное время детекции, размере объекта, координатах объекта в кадре;

отправку сформированного информационного сообщения в Подсистему обмена событиями;

формирование и отправку в ПОС кадра (изображения) детектированного объекта в формате
JPEG или PNG, при чем объект выделяется на изображении с помощью рамки.
4.2.15.3 Распознаватель государственных регистрационных номеров автотранспортных
средств
Распознаватель ГРН предназначен для решения базовой задачи распознавания номеров, а также
является компонентом для решения ряда функциональных задач, включая контроль деятельности
хозяйственных служб и контроль нарушения правил парковки.
Распознаватель ГРН обеспечивает:

идентификацию
и
распознавание
регистрационного
номера
автомобиля
(включая
автоматическое определение принадлежности к стране и типа номерной пластины);

надежное (95-98%) распознавание номеров автотранспортных средств, движущихся на
скорости до 160 км/ч в различных условиях, в т.ч. в разное время суток;

формирование сообщения содержащего информацию о распознанном номере, дате и
точном времени определения номера (при чем временная отметка соответствует кадру
видеоряда, на котором номерная пластина имеет наилучшую читаемость), направлении
проезда и координатах номерной пластины в кадре;

отправку сформированного информационного сообщения в Подсистему обмена событиями
(ПОС);

формирование и отправку в ПОС кадра (изображения) в формате JPEG или PNG, в котором
номерная пластина имеет наилучшую читаемость, при чем номерная пластина должна
выделяется на изображении с помощью рамки;

сопоставление распознанного номера с информацией из баз данных (внутренней или
внешней, включая базу данных ПОС).
4.2.15.4 Трекер субъектов
Трекер субъектов предназначен для решения базовой задачи трекинга объектов, а также является
компонентом для решения ряда функциональных задач по формированию гипотез о сущности
объектов и значении их движения, включая определение людей, определение праздношатания и
незаконной торговли, определение нехарактерного поведения людей (резкое изменение скорости,
падение).
Трекер субъектов обеспечивает:

детекцию и трекинг движущихся объектов (людей) в кадре (сцене);

фильтрацию результатов детекции в соответствии с заранее заданными размерами объекта
и границами контрольной зоны;

при выполнении дополнительный условий (пресечение границ зоны, пересечение
контрольной линии) формирование сообщения, содержащего информацию о
детектированном объекте (объектах), включая дату и точное время детекции, ID объекта,
размер объекта, координаты объекта в кадре;

отправку сформированного информационного сообщения в Подсистему обмена событиями
(ПОС);

формирование и отправку в ПОС кадра (изображения) детектированного объекта
(человека) в формате JPEG или PNG, при чем объект выделяется на изображении с
помощью рамки.
4.2.15.5 Детектор парковки
Детектор парковки предназначен для решения функциональной задачи определения
потенциально-опасных ситуаций с участием автотранспортных средств (остановка в
неположенном месте, нарушение правил парковки) на базе детекции появившихся объектов и
определения ГРН автотранспортного средства.
Детектор парковки обеспечивает:

определение появившихся объектов (предположительно автотранспортных средств) в
контрольной зоне;

формирование и отправку в ПОС сообщения, содержащего информацию о
детектированном объекте (автотранспортном средстве), включая дату и точное время
детекции, размер объекта, координаты объекта в кадре;

формирование и отправку в ПОС кадра (изображения) детектированного объекта в формате
JPEG или PNG, при чем объект выделяется на изображении с помощью рамки.
4.2.15.6 Детектор праздношатания
Детектор праздношатания предназначен для решения функциональных задач по формированию
гипотез о сущности объектов и значении их движения, в части определения праздношатания и
незаконной торговли.
Детектор праздношатания обеспечивает:

детекцию и трекинг движущихся объектов (людей) в кадре (сцене);

фильтрацию результатов детекции в соответствии с заранее заданными размерами объекта
и границами контрольной зоны;

при выполнении заранее заданных условий (пресечение границ зоны или контрольной
линии, нахождение в зоне на протяжении определенного времени, замедление движения и
остановка) формирование сообщения, содержащего информацию о детектированном
объекте (объектах), включая дату и точное время детекции, ID объекта, размер объекта,
координаты объекта в кадре;

отправку сформированного информационного сообщения в Подсистему обмена событиями
(ПОС);

формирование и отправку в ПОС кадра (изображения) детектированного объекта
(человека) в формате JPEG или PNG, при чем объект выделяется на изображении с
помощью рамки.
4.2.15.7 Детектор нехарактерного движения
Детектор нехарактерного движения предназначен для решения функциональных задач по
формированию гипотез о сущности объектов и значении их движения, в части определения
нехарактерного поведения людей (резкое изменение скорости, падение).
Детектор нехарактерного обеспечивает:

детекцию и трекинг движущихся объектов (людей) в кадре (сцене);

фильтрацию результатов детекции в соответствии с заранее заданными размерами объекта
и границами контрольной зоны;

при выполнении заранее заданных условий (пресечение границ зоны или контрольной
линии, резкое изменение скорости движения, резкое изменение размеров объекта)
формирование сообщения, содержащего информацию о детектированном объекте
(объектах), включая дату и точное время детекции, ID объекта, размер объекта, координаты
объекта в кадре;

отправку сформированного информационного сообщения в Подсистему обмена событиями
(ПОС);

формирование и отправку в ПОС кадра (изображения) детектированного объекта
(человека) в формате JPEG или PNG, при чем объект выделяется на изображении с
помощью рамки.
4.2.15.8 Детектор толпы Статистической-MD (на основе зонального детектора движения)
Детектор толпы Статистический-MD предназначен для решения функциональной задачи по
формированию гипотез о сущности объектов и значении их движения в части детектирования
появления и движения толпы.
Детектор толпы Статистический-MD обеспечивает:

определение движения в отдельных областях кадра за счет разбиения кадра на
координатную сетку 10х10 (100 ячеек) и детектирования движения в каждой ячейке;

фильтрацию результатов детекции в соответствии с заранее заданными границами
контрольной зоны;

формирование по расписанию и отправку в ПОС сообщения, содержащего информацию о
наличии/отсутствии
движения
в
каждой
ячейке
детектированном
объекте
(автотранспортном средстве), включая дату и точное время детекции.
4.2.15.9 Детектор толпы Статистический-TR (на основе детекции подвижных объектов и
вычисления относительной площади заполнения)
Детектор толпы Статистический-TR предназначен для решения функциональной задачи по
формированию гипотез о сущности объектов и значении их движения в части детектирования
появления и движения толпы.
Детектор толпы Статистический-TR обеспечивает:

определение движения в отдельных областях кадра за счет детекции движущихся объектов;

расчет отношения площади движущихся объектов к общей площади контрольной зоны;

формирование по расписанию и отправку в ПОС сообщения, содержащего информацию об
относительной площади движущихся объектов в пределах контрольной зоны, включая дату
и точное время детекции.
4.2.15.10
Детектор толпы Пороговый (на основе детекции общего уровня движения в
контрольной зоне)
Детектор толпы Пороговый предназначен для решения функциональной задачи по формированию
гипотез о сущности объектов и значении их движения в части детектирования появления и
движения толпы.
Детектор толпы Пороговый обеспечивает:

определение общего уровня движения в контрольной зоне и сравнение уровня движения с
заранее заданным порогом срабатывания;

при срабатывании детектора – формирование и отправку в ПОС сообщения содержащего
информацию о детекции, включая дату и точное время детекции.
4.2.16 Бизнес функциональные требования к услугам B2B сегмента
4.2.17 Бизнес функциональные требования к услугам B2С сегмента
4.2.18 Бизнес функциональные требования к интерфейсам пользователя
4.2.19 Бизнес функциональные требования к взаимодействию с бизнес системами Заказчика
4.3 Требования к видам обеспечения
4.3.1
Требования к информационному обеспечению
При разработке информационного обеспечения должны быть соблюдены следующие
основные принципы:
 принцип
оптимального
представления
информации:
реализация
данного
принципа должна быть достигнута за счет использования различных видов
представления данных;
 принцип единого понятийного базиса: реализация данного принципа должна быть
достигнута за счет формирования и поддержания в актуальном состоянии на всем
жизненном цикле проекта единого тезауруса определяющего понятия, объекты,
алгоритмы и т.д.
Информационное обеспечение должно быть достаточным для выполнения всех
автоматизированных функций Системы.
Информационное
обеспечение
должно
быть
совместимо
с
информационным
обеспечением систем, взаимодействующих с ней, по содержанию, системе кодирования,
методам адресации, форматам данных и форме представления информации, получаемой и
выдаваемой Системой.
Система классификации и кодирования информации должна представлять собой комплекс
классификаторов, обеспечивающих однозначность понятий и удобный диалог пользователя с
системой.
Классификаторы должны удовлетворять следующим требованиям:
 обеспечить полноту охвата объектов классификации;
 иметь необходимую глубину классификации, достаточную для обработки данных;
 обладать достаточной гибкостью для детализации признаков при расширении
множества объектов и их групп без нарушения структуры классификатора;
 сопрягаться с другими классификаторами однородных объектов;
 иметь защиту от дублирования записей.
Использование справочников должно обеспечить достижение следующих целей:
 облегчение работы пользователей по вводу информации в систему;
 уменьшение количества ошибок при вводе информации;
 увеличение поисковых возможностей системы;
 уменьшения потребности в дисковой памяти для базы данных.
Ведение
справочников
обеспечивает
централизованное
ведение
общесистемной
информации, контроль за состоянием и целостностью информационной базы Системы. Для
обеспечения корректной работы системы необходимо регулярно производить проверку
справочников.
Уровень хранения данных в системе должен быть построен на основе современных
объектно-реляционных СУБД. Для обеспечения логической и физической целостности данных
должны использоваться встроенные механизмы СУБД.
4.3.2
Требования к лингвистическому обеспечению
Система должна строиться с использованием графического интерфейса пользователя.
Взаимодействие пользователей с системой посредством графического интерфейса должно
происходить на русском языке.
4.3.3
Требования к программному обеспечению
Программное обеспечение системы должно учитывать требования к компонентам
Системы, указанным в разделе 4.2 настоящего ТЗ.
В состав программного обеспечения должны быть включены средства, обеспечивающие
выполнение следующих функций:
 управления и администрирования программно-технических средств Системы;
 управления и администрирования операционных систем и общесистемного ПО
Системы;
 диагностики и контроля процесса эксплуатации всех видов программнотехнических средств и программного обеспечения.
4.3.4
Требования к техническому обеспечению
Техническое обеспечение должно включать:
 технические средства обработки данных;
 технические средства передачи данных;
 технические средства вычислительных систем.
Комплекс технических средств обработки данных для решения функциональных задач
должен включать следующие основные компоненты:
 серверные
платформы,
которые
поддерживают
функционирование
общесистемного и прикладного ПО;
 оборудование сети хранения данных, обеспечивающее предоставление ресурсов
хранения для компонентов Системы;
 оборудование локальной вычислительной сети, которое создает коммутационную
среду взаимодействия компонентов Системы;
 рабочие
станции,
которые
обеспечивают
работу
пользователей
на
соответствующих рабочих местах;
 телекоммуникационное оборудование, которое поддерживает информационный
обмен между компонентами Системы, средствами видеонаблюдения, внешними
ИС и пользователями.
Обмен информацией между компонентами Системы должен обеспечиваться средствами
ЛВС, а с внешними ИС и пользователями - по выделенным или коммутируемым каналам с
использованием унифицированных транспортных протоколов.
Программно-технические средства Системы, осуществляющие оперативное хранение и
обработку видеоизображений, должны удовлетворять следующим требованиям:
 обеспечивать
одновременную
работу
с
видеоизображениями
расчетного
количества пользователей;
 обеспечивать оперативное хранение и обработку служебной информации, в т.ч.
баз данных;
 обеспечивать хранение и обработку видеоизображений;
 обеспечить возможность наращивания вычислительных мощностей системы
путем увеличения числа процессоров, оперативной памяти, дисковых подсистем;
 обеспечивать архивирование и восстановление служебной информации, в т.ч. баз
данных, без потери информации;
 обеспечивать выполнение требований по надежности системы в целом.
Электропитание всех составных частей системы должно осуществляться от электрической
сети переменного тока 220 В частотой 50 Гц.
Создание Системы не должно требовать специального оборудования либо специальных
материалов. При дальнейшей эксплуатации должна сохраняться возможность модернизации
системы с целью улучшения ее характеристик.
4.3.5
Требования к метрологическому обеспечению
Требований к метрологическому обеспечению не предъявляется.
4.3.6
Требования к организационному обеспечению
Состав, количество групп персонала, типы (роли) ответственности и разграничения по
ним определяются в рамках соответствующих Распоряжений и/или решений Оператора
Системы.
Персонал Оператора Системы в своей деятельности руководствуется Регламентом
функционирования
Системы,
должностными
инструкциями,
другими
внутренними
распоряжениями и/или решениями Оператора Системы.
Для каждой категории пользователей в составе эксплуатационной документации на
клиентское
ПО
должны
быть
разработаны
рабочие
инструкции,
определяющие
и
регламентирующие их действия.
Оператор Системы несет ответственность за выполнение требований безопасности
информации, обрабатываемой в Системы. Персонал Оператора Системы несет ответственность
за неразглашение сведений, ставших ему известными в ходе выполнения функциональных
и/или должностных обязанностей.
Контроль за функционированием Системы, проведение регламентных работ, устранение
отказов и сбоев должны осуществляться обслуживающим персоналом, который в своих
действиях должен руководствоваться соответствующими инструкциями.
4.3.7
Требования к методическому и другим видам обеспечения
Требования к методическому и другим видам обеспечения не предъявляются.
Download