если в тексте документа явно не указано, что данная

ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
БФТ
видеонаблюдения для сегмента
B2C
Стадии 1 и 2 (план)
1
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
История изменений документа
Дата
Версия Внесенные изменения
Причина
изменений/
инициатор изменения
Автор версии
07.04.14
1.0
Создание документа
Коломбет С.В.
30.04.14
2.0
Изменение
документа
в
соответствии
с
коммерческой
стратегией
по
видеонаблюдению
МТС-МГТС-АФК
М. Гарусев
23.06.14
3.0
Изменения
в
документе согласно
защищенного
бизнес-кейса
Коломбет С.В.
11.12.14
4.0
Изменения для RFI
Коломбет С.В.
2
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
1. Оглавление
1.
Оглавление .............................................................................................................................. 3
2.
Назначение документа ....................................................................................................... 6
3.
Предпосылки продукта ....................................................... Error! Bookmark not defined.
4.
Постановка задачи ................................................................ Error! Bookmark not defined.
5.
Описание продукта .............................................................................................................. 6
5.1.
Концепция услуги ......................................................................................................... 6
5.2.
Краткое описание продукта ..................................................................................... 6
5.3.
Схема организации услуги ....................................................................................... 7
5.4.
Технологическая схема продукта ......................................................................... 9
5.5.
Состав продукта ..........................................................................................................10
6.
Базовые сценарии подключения/активации услуги. .........................................12
6.1.
Базовый сценарий (Обязательный сценарий) – Подключение камеры
МГТС из сети GPON МГТС ........................................................................................................12
6.2.
Базовый сценарий (Обязательный сценарий) – Подключение камеры
МГТС из сети чужого оператора (Стадия 2) ...................................................................14
6.3.
Базовый сценарий (Обязательный сценарий) – Подключение
сторонней камеры Абонента из сети GPON МГТС ........................................................17
6.4.
Базовый сценарий (Обязательный сценарий) – Подключение
сторонней камеры Абонента из сети чужого оператора (Стадия 2)............. Error!
Bookmark not defined.
6.5.
Базовый сценарий – Подключение услуги «Моя квартира:
видеоархив» ..................................................................................................................................20
6.6.
Базовый сценарий – Подключение услуги ВА «Умная квартира»
(Стадия 2). .....................................................................................................................................21
7.
Базовые сценарии функционирования услуги. ....................................................22
7.1.
Функционирование базовой услуги ВА «Базовая видеоаналитика:
датчик работоспособности камеры» (Стадия 2) ..........................................................22
7.2.
Функционирование базовой услуги ВА «Базовая видеоаналитика:
датчик движения» (Стадия 2). .............................................................................................23
7.3.
Функционирование базовой услуги ВА «Базовая видеоаналитика:
датчик задымления / пожара» (Стадия 2). ....................................................................23
3
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
7.4.
Функционирование базовой услуги «Моя квартира: видеоархив» –
Запись в архив.............................................................................................................................24
8.
Базовые сценарии управления услугой. .................................................................25
8.1.
Базовый сценарий смены периода архивации видеоданных. ...............25
8.2.
Базовый сценарий настройки уведомлений о событиях через e-mail
(Стадия 2). .....................................................................................................................................26
8.3.
Базовый сценарий настройки уведомлений о событиях через SMS
(Стадия 2). .....................................................................................................................................27
8.4.
Базовый сценарий настройки уведомлений о событиях через Push
notification (Стадия 2)...............................................................................................................28
8.5.
Базовый сценарий управления доверенными мобильными
устройствами (Стадия 2). ........................................................................................................28
8.6.
9.
Базовый сценарий управления Услугой с мобильного устройства .....29
Базовые сценарии использования услуги...............................................................30
9.1.
Базовый сценарий – Просмотр видео изображения с камер .................30
9.2.
Базовый сценарий – Просмотр видео изображения в видеоархиве ...31
9.3.
Базовый сценарий – Пассивная постановка на охрану (Стадия 2) ....31
9.4.
Базовый сценарий сохранения архивированных видеоданных на
внешний носитель (Стадия 2). .............................................................................................32
10.
Отключение услуги через ЛК ......................................................................................33
10.1.
Базовый сценарий отключения услуги «Умная квартира» (Стадия 2)
33
10.2.
Базовый сценарий отключения услуг «Моя квартира (видеоархив)»
34
10.3.
Базовый сценарий отключения услуг «Моя квартира» ............................35
11.
Требования к тарификации ...........................................................................................36
12.
Базовые требования ..........................................................................................................37
12.1.
Поддержка абонентов ...............................................................................................37
12.2.
Поддержка абонента в Инцидент-менеджмента ..........................................37
13.
Территория предоставления Продукта .....................................................................37
14.
Требования к финансово – юридической схеме Продукта .............................39
15.
Требования к отчетности ................................................................................................39
16.
Требования к бизнес KPI работы Продукта............................................................39
4
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
17.
Требования к нагрузке на Продукт ............................................................................39
18.
Требования к абонентскому оборудованию ...........................................................40
18.1.
IP видеокамеры............................................................................................................40
18.2.
Коммутаторы .................................................................................................................42
19.
Требования к сервисной платформе ............................ Error! Bookmark not defined.
20.
Этапы реализации Продукта ............................................ Error! Bookmark not defined.
21.
Риски Продукта ....................................................................... Error! Bookmark not defined.
22.
Требование к статистике .................................................................................................42
23.
Приложение 1 «Модели пользовательских интерфейсов к Продукту» .....42
24.
Приложение 2 «High Level Design» ............................... Error! Bookmark not defined.
5
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
ВНИМАНИЕ: если в тексте документа явно не указано, что данная
функциональность относиться к Стадии 2, то данная функциональность
должна быть реализована на Стадии 1.
2. Назначение документа
В настоящем документе изложены бизнес–функциональные требования к
составу и содержанию по видеонаблюдению (ВН) и видеоаналитике (ВА) МГТС
для сегмента В2С (далее - Услуги), предназначенные для реализации проекта,
а так же базовые требования к архитектуре и способу реализации Услуги.
Версия
данного
документа
являться
основой
для
инициации
разработки/доработки
программных
приложений/систем,
разработки
требований,
выбора
и
закупку
программно–аппаратного
комплекса
обеспечивающих предоставление Услуги. Документ предназначен для передачи
исполнителю/разработчику Услуги, сотрудникам подразделений компании МГТС
отвечающим за разработку и поддержку работоспособности ИТ систем
задействованных в предоставлении Услуги.
3. Описание продукта
3.1. Концепция услуги
Услуга предоставляется Абонентам МГТС преимущественно ориентированным
на использование технологии GPON. Предоставляется возможность
видеонаблюдения за объектом Абонента, создание структурированного
видеоархива и возможность аналитической обработки видеоизображения.
Инфраструктура услуги располагается на вычислительных площадях Оператора
предоставляя пользователю доступ к услуге из любой точки подключения к
Интернет.
3.2. Краткое описание продукта
Услуга предоставляется абонентам МГТС сегмента B2C и преимущественно
ориентированным на использование технологии GPON. Предоставляется
возможность видеонаблюдения на объекте, создание структурированного
видеоархива событий и возможность аналитической обработки
видеоизображения по средством машинного зрения. Инфраструктура услуги
6
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
располагается на вычислительных площадях Оператора предоставляя
Пользователю доступ к услуге из любой точки мира.
3.3. Схема организации услуги
МГТС GPON
C
Internet
Рис. 1 Простая схема организации услуги
7
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
L
MP
еть
SС
ТС
МГ
Сервера VMS
Платформа
Видеонаблюдения
N
VP
Сервер приложений
WiFi AP**
In
te
rn
et
Second SSID*
ONT
* На WIFI текущего оборудование ONT Подключается не более 2-х потоков с камер, один поток не более 2 Мбит/с
** На дополнительную WiFi AP Не более Х камер заданных характеристик
Рис. 2 Верхнеуровневая сетевая схема предоставления услуги
8
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
3.4. Технологическая схема продукта
GPON
(2) Сервисная
платформа
(1) Подсистема
Видеонаблюдения
(3) Интерфейс
Крипто шлюз
6. Видео и события
Крипто шлюз
1. Управление
видеопотоками
ит
ео
ан
ал
Ви
д
4.
(4) Подсистема
видеоаналитики
ик
а
Крипто шлюз
3. Видео
5. Массивы данных
VPN
Крипто шлюз
2. Видео
Территория пользователя
Видеосервера
ИТ системы
МГТС
Планшет
(5) Подсистема
хранения данных
Смартфон
Интерфейсы
пользователя
ПК
Рис. 3 Технологическая схема организации услуги
9
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
TCP/IP
Платформа видеонаблюдения
TCP/IP
C
TCP/IP
IP
IP MPLS
MPLS
МГТС
МГТС
TCP/IP
API
Камеры по проекту
«Безопасный город»
ЕЦХД
ЕЦХД
C
Камеры МГТС
«Безопасный город»
ForisFix
ForisFix
TCP/IP
API
TCP/IP
API
Камеры пользователей
Сеть
Сеть другого
другого
оператора
оператора
API
Личный
Личный
кабинет
кабинет
ЕЛК
ЕЛК
C
МГТС
C
TCP/IP
Камеры пользователей на сетях
другого оператора
Информация о начисленях
API
АСРЗ
АСРЗ
API
Далекое будущее
CRM
Siebel
Ordering
Oracle OSM
Система
управления
инцидентами
Remedy
ЕБД
ЕБД
Inventory
Начисления по услуге
Net Cracker
Prebill
Рис. 4 Верхнеуровневая схема взаимодействия с АСРЗ
3.5. Состав продукта
Услуга должна состоять из следующих блоков или подсистем как
самостоятельных, так и комбинированного типа:
Сервисная платформа – предназначена для объединения подсистем услуги в
единое информационное пространство, обеспечения взаимодействия подсистем
между собой, отработку сценариев управления услугой. В сервисной
платформе должна быть возможность реализации акций проводимых в рамках
развития и продвижения услуги Видеонаблюдения. Сервисная платформа
должна позволять создавать и управлять профилями пользователей, назначать
роли и приоритеты управления камерами, отдавать команды на настройку
камер на платформе, обеспечивать выполнение бизнес процессов продажи и
обслуживания услуги Видеонаблюдение.
Подсистема Видеонаблюдения – предназначена для агрегации сигналов с
камер Пользователя и распределение потоков на смежные подсистемы. Должна
иметь функцию провиженинга новых пользователей / новых камер для
существующих пользователей и функцию предоставления Биллингу МГТС
данных:
10
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.




по
по
по
по
подключенным пользователям
подключенным камерам у пользователей
емкости использования дискового хранилища пользователями
полосе пропускания от подключенных камер пользователей
Подсистема Видеоаналитики – предназначена для реализации
аналитических сценариев, на основе которых реализуется структурированное,
событийное представление видеоинформации Пользователю. Должна иметь
функцию провиженинга своих детекторов на существующие камеры для
существующих пользователей и функцию предоставления Биллингу МГТС
данных:


по подключенным модулям на камеры у пользователей
по частоте срабатывания детектора
Подсистема хранения данных – предназначена для хранения
видеоизображения с камер в полном объеме или по команде от смежных
подсистем.
ИТ-системы компании:
Биллинг – расчетная система, предназначенная для ведения учета
потребления услуги абонентом. Должен иметь внешние интерфейсы или иметь
возможность использовать интерфейсы интеграционной платформы



CRM
SAP/OEBS
Система гарантирования доходов
Интерфейсы пользователя – графические интерфейсы пользователя для
доступа с компьютера, и мобильных устройствах, предназначенные для
пользования и управления услугой со стороны абонента.
Пользовательский интерфейс должен быть совместим:





Операционные системы: Windows XP– Windows 7, MacOS, Семейство
Unix (Free BSD, Red Hat, Debian) , Windows Phone (Mobile) 6 и выше
(Стадия 2), iOS, Android (Стадия 2).
Браузеры: IE, Firefox, Safari, Opera, Google Chrome.
Доступ с устройств РС: только в браузерном режиме, без «толстого»
клиента
Доступ с мобильных устройств: Android (клиент должен быть
представлен в магазине Google Play) (Стадия 2), iPhone (клиент должен
быть представлен в магазине AppStore), на Стадии 2 - Смартфоны на
Windows Phone Mobile (клиент должен быть представлен в магазине
Microsoft)
Верстка: Интерфейс услуги должен быть адаптирован под разрешение
1024х768, 176х208, 320х240, 640х480.
11
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
4. Базовые сценарии подключения/активации услуги.
4.1. Базовый
сценарий
(Обязательный
сценарий)
Подключение камеры МГТС из сети GPON МГТС
–
Назначение сценария: Сценарий описывает порядок настройки ONT GPON
подключения камеры МГТС к платформе видеонаблюдения (Системе) и
подключения услуги «Моя квартира».
Участники сценария: Абонент, Система, ONT, ЕЛК, видеокамера МГТС.
Исходные данные сценария:
Абонент является потребителем услуг GPON от МГТС.
В Камере загружен микрокод обеспечивающий подключение к платформе
Видеонаблюдения МГТС.
У Абонента есть выход в сеть Интернет через Абонентское устройство.
На Абонентском устройстве включена раздача IP адресов по протоколу DHCP.
Критерии успешности сценария: Камера доступна на платформе
Видеонаблюдения и появилась в ЕЛК абонента.
Базовые шаги сценария:
4.1.1.
Абонент создает заявку на подключение услуги «Моя квартира» в
ЕЛК для B2C клиента или через ЦПиО.
4.1.2.
Камера подключается к сети Internet
4.1.3.
Если у абонента 2 и более видеокамеры, то абоненту требуется
установка коммутатора.
4.1.4.
Вторая и последующие камеры должны быть подключены к
Интернет через коммутатор или по WiFi сети:
4.1.4.1. Абоненту предоставляется коммутатор в рамках услуги.
4.1.4.2. Абонент
покупает
коммутатор
у
МГТС,
удовлетворяющий
требованиям к Услуге, за свои деньги. Также Абонент может
приобрести коммутатор/ использовать имеющийся (при условии
соотв. тех. требованиям в п.4.1.4.2)
4.1.4.3. Коммутатор должен удовлетворять следующим минимальным
требованиям:
 Поддержка питания PoE и HPoE в зависимости от требований
камеры и условий установки
 Максимальное количество камер (используемые профили для
формата H.264 Baseline Profile или Main Profile) подключаемое
к ONT кабелем определяется пропускной способностью
12
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
сетевого, пользовательского оборудования и из расчета
видеопотока на одну камеру 2 Мбит/с.

Максимальное количество камер (используемые профили для
формата H.264 Baseline Profile или Main Profile) подключаемое к
ONT через WiFi (с помощью WPS)
определяется пропускной
способностью сетевого, пользовательского оборудования и из
расчета видеопотока на одну камеру 2 Мбит/с.
4.1.5.
После подключения питания и патч-корда или к сети WiFi, камера
переходит
в
режим
подключения
Камеры
к
платформе
Видеонаблюдения:
4.1.5.1. Камера получает IP адрес по протоколу DHCP от абонентского
устройства.
4.1.5.2. Камера сама устанавливает защищенное соединение с платформой
Видеонаблюдения
(камера
должна
обеспечивать
закрытие
видеопотока).
4.1.5.3. Камера отправляет на платформу Видеонаблюдения уведомления с
идентификационными данными камеры (MAC адрес)
4.1.6.
После ручного закрытия Абонентом информационного окна в ЛК
открывается окно для ввода идентификационных данных
подключаемой камеры МГТС. Идентификационные данные Камеры
определяются на этапе проектирования Сервисной платформы, под
идентификационными данными понимается уникальный номер, по
которому платформа сможет определить камеру и привязать к
абоненту.
4.1.7.
В ЕЛК услуги Абонент вносит идентификационные данные
подключаемой камеры.
4.1.8.
Платформа Видеонаблюдения получает уведомление от Камеры к
платформе
Видеонаблюдения.
В
уведомление
содержатся
индивидуальные данные о Камере.
4.1.9.
Платформа Видеонаблюдения сравнивает данные полученные от
Камеры и введенные Абонентом в п. 4.1.6.
4.1.10. Если идентификационные данные, полученные в пунктах Error!
Reference source not found. и 4.1.6 совпадают, Система пытается
получить
видеопоток
с
камеры.
В
процессе
получения
видеопотока, в окне отображения находится надпись «Подождите,
идет настройка вашей камеры».
4.1.11. Система получает поток с камеры, после чего система переходит на
страницу просмотра камеры.
4.1.12. В ЕЛК / мобильном устройстве открывается страничка просмотра
видеоизображения с камеры и возможность дальнейшей работы с
Услугой или подключение дополнительных опций.
4.1.13. В журнале операций ЕЛК по услуге «Моя квартира» делается
отметка, что о подключении камеры абоненту.
13
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
4.1.14.
4.1.15.
4.1.16.
4.1.17.
В биллинг заносится информация о подключенной услуге и
начинается тарификация услуги «Моя квартира».
(Стадия 2) Система дает команду на подключение базовой услуги
ВА «Базовая видеоаналитика: датчик движения» для данной
камеры. В биллинг заносится информацию о подключенной услуге
ВА и начинается тарификация услуги «Базовая видеоаналитика:
датчик движения».
(Стадия 2) Система дает команду на подключение базовой услуги
ВА «Базовая видеоаналитика: датчик задымления / пожара» для
данной камеры. В биллинг заносится информацию о подключенной
услуге
ВА
и
начинается
тарификация
услуги
«Базовая
видеоаналитика: датчик задымления / пожара».
(Стадия 2) Система дает команду на подключение базовой услуги
ВА «Базовая видеоаналитика: датчик работоспособности камеры»
для данной камеры. В биллинг заносится информацию о
подключенной услуге ВА и начинается тарификация услуги
«Базовая видеоаналитика: датчик работоспособности камеры».
Альтернативные сценарии:
4.1.18.
Если Системе не получается сопоставить данные от камеры и
абонента. Камера не подключена к системе, в ЕЛК выводится
уведомление о невозможности подключить камеру и сообщение
«Повторите, пожалуйста, ввод идентификационных данных
видеокамеры».
4.1.19. Если система не может получить поток с камеры в течение Х
секунд (параметр настраивается в Системе), то выводится окно с
сообщением «Невозможно получить поток с камеры» в окне
размещается ссылка на описание возможных проблем и их
решение.
4.1.20. Если Камера имеет возможность подключения по WiFi:
4.1.20.1. В ЛК услуги, в разделе настройка и подключения Камеры Абонент
может выбрать доступные на камере WiFi подключения или ввести
данные от своей WiFi сети.
4.1.20.2. Система передает данные о подключении к WiFi сети в камеру
4.1.20.3. Камера подключена к WiFi сети абонента.
4.2. Базовый
сценарий
(Обязательный
сценарий)
–
Подключение камеры МГТС из сети чужого оператора
(Стадия 2)
14
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
Назначение сценария: Сценарий описывает порядок подключения камеры
МГТС к платформе видеонаблюдения (Системе) и подключения услуги «Моя
квартира» на сети ADSL МГТС или на сети чужих операторов.
Участники сценария: Абонент, Система, роутер абонента, ЕЛК, видеокамера
МГТС.
Исходные данные сценария:
У Абонента есть собственный роутер, подключенный к сети Интернет.
В Камере загружен микрокод обеспечивающий подключение к платформе
Видеонаблюдения МГТС.
У Абонента есть выход в сеть Интернет через Абонентское устройство.
На Абонентском устройстве включена раздача IP адресов по протоколу DHCP.
Критерии успешности сценария: Камера доступна на платформе
Видеонаблюдения и появилась в ЕЛК абонента.
Базовые шаги сценария:
4.2.1.
Абонент создает заявку на подключение услуги «Моя квартира» в
ЕЛК для B2C клиента или через ЦПиО.
4.2.2.
Скорость upload-Интернет-подключения в сторону Оператора от
Абонента ограничивает подключение камер из расчета в 2
Мбит/сек на 1 камеру. ЕЛК выдает в сообщении абоненту таблицу
соответствия скоростей и количества камер..
4.2.3.
Если у абонента 2 и более видеокамеры, то абоненту требуется
коммутатор.
4.2.4.
Вторая и последующие камеры должны быть подключены к
интернету с помощью коммутатора:
4.2.4.1. Абоненту предоставляется коммутатор в рамках услуги.
4.2.4.2. Абонент
покупает
коммутатор
у
МГТС,
удовлетворяющий
требованиям к Услуге, за свои деньги. Также Абонент может
приобрести коммутатор/ использовать имеющийся (при условии
соотв. тех. требованиям в п.4.1.4.2)
4.2.4.3. Коммутатор должен удовлетворять следующим минимальным
требованиям:
 Поддержка питания PoE и HPoE в зависимости от требований
камеры и условий установки
 Максимальное количество камер (используемые профили для
формата H.264 Baseline Profile или Main Profile) подключаемое
к ONT кабелем определяется пропускной способностью
сетевого, пользовательского оборудования и из расчета
видеопотока на одну камеру 2 Мбит/с.
 Максимальное количество камер (используемые профили для
формата H.264 Baseline Profile или Main Profile) подключаемое
к ONT через WiFi определяется пропускной способностью
15
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
4.2.5.
4.2.5.1.
4.2.6.
4.2.6.1.
4.2.6.2.
4.2.6.3.
4.2.7.
4.2.8.
4.2.9.
4.2.10.
4.2.11.
4.2.12.
4.2.13.
сетевого, пользовательского оборудования и из расчета
видеопотока на одну камеру 2 Мбит/с.
После того, как окно заявки на подключение услуги «Моя
квартира» в ЕЛК изменится на статус «Заявка подключена»,
Абонент подключает камеру к абонентскому устройству (роутеру) с
помощью патч-корда, прилагаемого к камере иил к WiFi сети
интернет с помощью WPS.
Абонент входит на свое Абонентское оборудование и обеспечивает
доступ к IP адресу и URL платформы Видеонаблюдения.
После подключения питания и патч-корда на камере, камера
переходит
в
режим
подключения
Камеры
к
платформе
Видеонаблюдения:
Камера получает IP адрес по протоколу DHCP от абонентского
устройства.
Камера
сама
устанавливает
соединение
с
платформой
Видеонаблюдения
(камера
должна
обеспечивать
закрытие
видеопотока).
Камера отправляет на платформу Видеонаблюдения уведомления с
идентификационными данными камеры
После закрытия Абонентом информационного окна «Заявка
принята. Выделите и настройте порт на Вашем клиентском
оборудовании для видеокамеры» в ЕЛК, ЕЛК открывает окно для
ввода идентификационных данных подключаемой камеры МГТС.
Идентификационные данные Камеры определяются на этапе
проектирования Сервисной платформы, под идентификационными
данными понимается уникальный номер, по которому платформа
сможет определить камеру и привязать к абоненту.
В ЕЛК услуги Абонент вносит идентификационные данные
подключаемой камеры.
Платформа Видеонаблюдения получает уведомление от Камеры к
платформе
Видеонаблюдения.
В
уведомление
содержатся
индивидуальные данные о Камере.
Платформа Видеонаблюдения сравнивает данные полученные от
Камеры и введенные Абонентом в п. 4.1.6.
Если идентификационные данные, полученные в пунктах Error!
Reference source not found. и 4.1.6 совпадают, Система пытается
получить
видеопоток
с
камеры.
В
процессе
получения
видеопотока, в окне отображения находится надпись «Подождите,
идет настройка вашей камеры».
Система получает поток с камеры, после чего система переходит на
страницу просмотра камеры.
В ЕЛК / мобильном устройстве открывается страничка просмотра
видеоизображения с камеры и возможность дальнейшей работы с
Услугой или подключение дополнительных опций.
16
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
4.2.14.
4.2.15.
4.2.16.
4.2.17.
4.2.18.
В журнале операций ЕЛК по услуге «Моя квартира» делается
отметка, что о подключении камеры абоненту.
В биллинг заносится информация о подключенной услуге и
начинается тарификация услуги «Моя квартира».
Система дает команду на подключение базовой услуги ВА «Базовая
видеоаналитика: датчик движения» для данной камеры. В биллинг
заносится информацию о подключенной услуге ВА и начинается
тарификация услуги «Базовая видеоаналитика: датчик движения».
Система дает команду на подключение базовой услуги ВА «Базовая
видеоаналитика: датчик задымления / пожара» для данной
камеры. В биллинг заносится информацию о подключенной услуге
ВА и начинается тарификация услуги «Базовая видеоаналитика:
датчик задымления / пожара».
Система дает команду на подключение базовой услуги ВА «Базовая
видеоаналитика: датчик работоспособности камеры» для данной
камеры. В биллинг заносится информацию о подключенной услуге
ВА и начинается тарификация услуги «Базовая видеоаналитика:
датчик работоспособности камеры».
Альтернативные сценарии:
4.2.19.
Если Системе не получается сопоставить данные от камеры и
абонента. Камера не подключена к системе, в ЕЛК выводится
уведомление о невозможности подключить камеру и сообщение
«Повторите, пожалуйста, ввод идентификационных данных
видеокамеры».
4.2.20. Если система не может получить поток с камеры в течение Х
секунд (параметр настраивается в Системе), то выводится окно с
сообщением «Невозможно получить поток с камеры» в окне
размещается ссылка на описание возможных проблем и их
решение.
4.2.21. Если Камера имеет возможность подключения по WiFi:
4.2.21.1. В ЛК услуги, в разделе настройка и подключения Камеры Абонент
может выбрать доступные на камере WiFi подключения или ввести
данные от своей WiFi сети.
4.2.21.2. Система передает данные о подключении к WiFi сети в камеру
4.2.21.3. Камера подключена к WiFi сети абонента.
4.3. Базовый
сценарий
(Обязательный
сценарий)
–
Подключение сторонней камеры Абонента из сети
GPON МГТС
17
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
Назначение сценария: Сценарий описывает порядок настройки ONT GPON
подключения камеры стороннего производителя к платформе видеонаблюдения
(Системе) и подключения услуги «Моя квартира».
Участники сценария: Абонент, Система, ONT, ЕЛК, видеокамера стороннего
производителя.
Исходные данные сценария:
Абонент является потребителем услуг GPON от МГТС.
У абонента есть своя камера.
У Абонента есть выход в сеть Интернет через Абонентское устройство.
На Абонентском устройстве включена раздача IP адресов по протоколу DHCP.
Критерии успешности сценария: Камера доступна на платформе
Видеонаблюдения и появилась в ЕЛК абонента.
Базовые шаги сценария:
4.3.1.
Абонент создает заявку на подключение услуги «Моя квартира» в
ЕЛК для B2C клиента или через ЦПиО.
4.3.2.
Камера подключается к сети Интрнет
4.3.3.
Если у абонента 2 и более видеокамеры, то абоненту требуется
установка коммутатора.
4.3.4.
Вторая и последующие камеры должны быть подключены через
указанный выделенный порт с помощью коммутатора:
4.3.4.1. Абоненту предоставляется коммутатор в рамках услуги.
4.3.4.2. Абонент
покупает
коммутатор
у
МГТС,
удовлетворяющий
требованиям к Услуге, за свои деньги. Также Абонент может
приобрести коммутатор/ использовать имеющийся (при условии
соотв. тех. требованиям в п.4.1.4.2)
4.3.4.3. Коммутатор должен удовлетворять следующим минимальным
требованиям:
 Поддержка питания PoE и HPoE в зависимости от требований
камеры и условий установки
 Максимальное количество камер (используемые профили для
формата H.264 Baseline Profile или Main Profile) подключаемое
к ONT кабелем определяется пропускной способностью
сетевого, пользовательского оборудования и из расчета
видеопотока на одну камеру 2 Мбит/с.
 Максимальное количество камер (используемые профили для
формата H.264 Baseline Profile или Main Profile) подключаемое
к ONT через WiFi определяется пропускной способностью
сетевого, пользовательского оборудования и из расчета
видеопотока на одну камеру 2 Мбит/с.
4.3.5.
После того, как окно заявки на подключение услуги «Моя
квартира» в ЕЛК изменится на статус «Заявка принята. Абонент
18
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
подключает камеру к абонентскому устройству (роутеру) с
помощью патч-корда, прилагаемого к камере или через WiFi.
4.3.6.
Абонент отмечает в ЕЛК признак «Своя камера».
4.3.6.1. ЕЛК предоставляет Абоненту два варианта подключения камеры:
«Подключить камеру из списка» и «Подключить неизвестную
камеру».
4.3.6.2. Настройка неизвестной Системе камеры:
4.3.6.2.1.
Абонент получает IP адрес камеры и порт подключения для
администрирования и для получения потока.
4.3.6.2.2.
Абонент запускает программу первичной настройки камеры.
Программное обеспечение для настройки камеры не входит в
предоставление
услуги.
Программное
обеспечение
для
настройки
камеры
может
быть
разработано
вендором
специально для подключения к платформе видеонаблюдения
МГТС.
4.3.6.2.3.
Абонент в интерфейсе камеры находит ссылку на поток (http
или rtsp).
4.3.6.2.4.
В диалоговом окне ЕЛК Абонент вставляет ссылку на поток,
полученную в пункте 4.3.6.1
4.3.6.2.5.
Нажимает «ОК»
4.3.6.3. Настройка известной Системе камеры из списка:
4.3.6.3.1.
Абонент выбирает в ЕЛК производителя камер из списка.
4.3.6.3.2.
Абонент выбирает в ЕЛК камеру из списка выбранного
производителя.
4.3.6.3.3.
Нажимает «ОК»
4.3.7.
Система пытается получить видеопоток с камеры. В процессе
получения видеопотока, в окне отображения находится надпись
«Подождите, идет настройка вашей камеры».
4.3.8.
Система получает поток с камеры, после чего система переходит на
страницу просмотра камеры.
4.3.9.
В ЕЛК / мобильном устройстве открывается страничка просмотра
видеоизображения с камеры и возможность дальнейшей работы с
Услугой или подключение дополнительных опций.
4.3.10. В журнале операций ЕЛК по услуге «Моя квартира» делается
отметка, что о подключении камеры абоненту.
4.3.11. В биллинг заносится информация о подключенной услуге и
начинается тарификация услуги «Моя квартира».
4.3.12. (Стадия 2) Система дает команду на подключение базовой услуги
ВА «Базовая видеоаналитика: датчик движения» для данной
камеры. В биллинг заносится информацию о подключенной услуге
ВА и начинается тарификация услуги «Базовая видеоаналитика:
датчик движения».
4.3.13. (Стадия 2) Система дает команду на подключение базовой услуги
ВА «Базовая видеоаналитика: датчик задымления / пожара» для
19
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
4.3.14.
данной камеры. В биллинг заносится информацию о подключенной
услуге
ВА
и
начинается
тарификация
услуги
«Базовая
видеоаналитика: датчик задымления / пожара».
(Стадия 2) Система дает команду на подключение базовой услуги
ВА «Базовая видеоаналитика: датчик работоспособности камеры»
для данной камеры. В биллинг заносится информацию о
подключенной услуге ВА и начинается тарификация услуги
«Базовая видеоаналитика: датчик работоспособности камеры».
Альтернативные сценарии:
4.3.15.
Если система не может получить поток с камеры в течение Х
секунд (параметр настраивается в Системе), то выводится окно с
сообщением «Невозможно получить поток с камеры» в окне
размещается ссылка на описание возможных проблем и их
решение.
4.3.16. Если Камера имеет возможность подключения по WiFi:
4.3.16.1. В интерфейсе видеокамеры Абонент самостоятельно настраивает
WiFi подключения к ONT.
4.4. Базовый сценарий –
квартира: видеоархив»
Подключение
услуги
«Моя
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях Android и Windows Mobile Phone.
Назначение сценария: сценарий описывает порядок подключения услуги
«Моя квартира: видеоархив».
Участники сценария: Абонент, Система, Камера.
Исходные данные сценария: У абонента подключена услуга «Моя
квартира». У абонента статус аккаунта «активен». У абонента
зарегистрировано одна и более камер.
Критерии успешности сценария: После прохождения сценария абонент
получил доступ к видеоархиву данных со своей камеры.
Базовые шаги сценария:
4.4.1.
4.4.2.
Абонент авторизован в ЕЛК или в мобильном приложении.
Абонент переходить в раздел «Моя квартира».
20
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
4.4.3.
4.4.4.
4.4.5.
4.4.6.
4.4.7.
Абонент переходит на вкладку управление архивом.
Абонент выбирает камеру и назначает для нее услугу
архивирования видеоданных.
Система предлагает выбрать период архивирования для камеры: 7,
(Стадия 2) - 14, 30 дней.
Абонент соглашается с ценами на архив и с этого момента Система
получает команду на тарификацию услуги.
Абонент переходит в раздел просмотра архива и может
просмотреть архив с камеры.
4.5. Базовый сценарий – Подключение услуги ВА «Умная
квартира» (Стадия 2).
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS и Android на Стадии 1. На Стадии 2 данный сценарий должен
быть реализован в мобильных приложениях для Windows Mobile Phone.
Назначение сценария: сценарий описывает порядок подключения услуги
«Умная квартира»
Участники сценария: Абонент, Система, Камера.
Исходные данные сценария: У абонента подключена услуга «Моя
квартира». У абонента статус аккаунта «активен». У абонента подключена одна
и более камер. Абонент не находится в состоянии финансовой блокировки.
Критерии успешности сценария: После прохождения сценария подключена
услуга видеоаналитики, абонент получает уведомления от системы
видеоаналитики о событиях.
Базовые шаги сценария:
4.5.1.
4.5.2.
4.5.3.
4.5.4.
4.5.5.
4.5.6.
4.5.7.
4.5.8.
4.5.9.
Абонент авторизован в ЕЛК или в мобильном приложении.
Абонент переходить в раздел «Моя квартира».
Абонент переходит на вкладку настройка видеоаналитики.
Абонент выбирает камеру и назначает для нее услугу
видеоаналитики: «Базовая видеоаналитика: датчик движения»
и/или «Базовая видеоаналитика: датчик задымления / пожара».
Система сообщает Абоненту о стоимости данной услуги.
Абонент подтверждает согласие с тарификацией.
Система переводит Абонента в раздел настройки видеоаналитики.
Абонент настраивает услугу видеоаналитики в соответствие с
описанием в Приложении Х (зависит от вендора используемой
видеоаналитики)
Абоненту приходят события в соответствии с настройками базовых
сценариев 6.2, 6.3, 6.4
21
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
4.5.10.
4.5.11.
4.5.12.
Абонент в ЛК услуги, в разделе архив сообщений может
просмотреть события за выбранный период времени.
Система предупреждает, что у абонента тарификация услуги
начнется на следующий день после подключения услуги и ему
будет начислена месячная стоимость услуги из расчета стоимости
до конца расчетного периода.
В ЕЛК услуги, отображаются последние Х (параметр определяется
настройками Системы и ЛК услуги) событий.
5. Базовые сценарии функционирования услуги.
5.1. Функционирование базовой услуги ВА «Базовая
видеоаналитика: датчик работоспособности камеры»
(Стадия 2)
Назначение сценария: Выявление нарушений работы камеры в
анализируемом видеопотоке.
Участники сценария: Система, камера, модуль видеоаналитики обнаружение
неисправности.
Исходные данные сценария: В систему видеоаналитики поступает
видеопоток с камеры. На поступающий видеопоток накладывается модуль
видеоаналитики для обнаружений нарушений в работе видеокамеры.
Критерии успешности сценария: Система способна обнаружить следующие
неисправности камеры:




Расфокусировку изображение
Засветление изображения
Затемнение изображения
Неработоспособность канала связи с камерой
Базовые шаги сценария:
5.1.1.
Система анализирует входящий видеопоток с камеры.
5.1.2.
Модуль видеоаналитики фиксирует неполадку на камере.
5.1.2.1. Если камера ранее была подключена, выполнены п.4.1, 4.2, 4.3
или Error! Reference source not found., то система отправляет
инцидент в систему технической поддержки услуги. Техническая
поддержка
проводит
выявление
и
устранение
причины
неисправности.
5.1.2.2. Если неисправность обнаружена в процессе выполнения п.4.1, 4.2,
4.3 или Error! Reference source not found., то система выводить
22
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
5.1.3.
сообщение абоненту о том, что камера не подключена или
подключена не верно.
События о неисправности камер сохраняются в журнале ЛК
5.2. Функционирование базовой услуги ВА «Базовая
видеоаналитика: датчик движения» (Стадия 2).
Назначение сценария: Выявление движущихся объектов в анализируемом
видеопотоке (кадре).
Участники сценария: Абонент, Система, камера.
Исходные данные сценария: В системе аналитики задана область контроля
для конкретной камеры. В системе аналитики заданы параметры определяемого
объекта. В систему аналитики поступает видеопоток с камеры, для которой
определена зона контроля.
Критерии успешности сценария: Система сохраняет в журнал событий
уведомления от системы видеоаналитики.
Базовые шаги сценария:
5.2.1.
5.2.2.
5.2.3.
5.2.4.
5.2.5.
Система фиксирует объекты в видеопотоке.
Система отмечает движущийся объект(ы)
Система создает запись в журнале событий в ЛК о движущемся
объекте(ах).
Если в Системе задано уведомление Абонента о срабатывании
данного датчика – Система отправляет уведомление через e-mail /
SMS / Push notification
Если в Системе установлена конфигурация услуги «Моя квартира
(видеоархив)» с записью по датчику движения, то Система
начинает запись события.
5.3. Функционирование базовой услуги ВА «Базовая
видеоаналитика: датчик задымления / пожара» (Стадия
2).
Назначение сценария: Выявление задымления / возгорания в анализируемом
видеопотоке (кадре).
Участники сценария: Абонент, Система, камера.
Исходные данные сценария: В системе аналитики задан признак контроля
задымления / пожара для конкретной камеры. В систему аналитики поступает
видеопоток с камеры, для которой определена зона контроля.
23
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
Критерии успешности сценария: Система сохраняет в журнал событий
уведомления от системы видеоаналитики.
Базовые шаги сценария:
5.3.1.
5.3.2.
5.3.3.
5.3.4.
5.3.5.
Система фиксирует поступающий видеопоток.
Система отмечает задымление / пожар
Система создает запись в журнале событий в ЛК о задымлении /
пожаре
Если в Системе задано уведомление Абонента о срабатывании
данного датчика – Система отправляет уведомление через e-mail /
SMS / Push notification
Если в Системе установлена конфигурация услуги «Моя квартира
(видеоархив)» с записью по датчику движения, то Система
начинает запись события.
5.4. Функционирование базовой услуги
видеоархив» – Запись в архив.
«Моя
квартира:
Назначение сценария: Сохранение видеопотока с камеры наблюдения в
систему хранения данных.
Участники сценария: Система, камера.
Исходные данные сценария: Входящий видео поток с камеры или от
системы видеоаналитики. Команда на запись от Системы/администратора о
начале или окончании записи.
Критерии успешности сценария:
В архив записываются видеофрагмент события. Видеоархив события может
быть просмотрен пользователем.
Базовые шаги сценария:
5.4.1.
5.4.2.
5.4.3.
Видеопоток с камеры пишется в буфер (может располагаться на
платформе Видеонаблюдения или на карте памяти камеры). Для
каждой камеры выделен свой буфер предварительной записи.
Размер буфера не менее 5 секунд. В качестве буфера
предварительной
записи
может
быть
использован
архив,
сохраняющийся на карте памяти в камере.
От системы видеоаналитики поступает сигнал о начале записи
видеопотока в архив
К временной метке начала записи (момент начала события)
добавляется дельта времени начала записи в архив (определяется
в ЧЧ:ММ:СС, должно гибко настраиваться в системе)
24
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
5.4.4.
5.4.5.
5.4.6.
5.4.7.
От системы аналитики поступает сигнал окончания записи
видеопотока
в
архив.
Прекращение
движения
в
кадре,
прекращение работы сценария видеоаналитики.
К временной метке окончания записи (момент окончания события)
добавляется дельта времени окончания записи в архив
(определяется в ЧЧ:ММ:СС, должно гибко настраиваться в системе)
На записанный видео поток создается отметка (метаданные о
работе системы видеоаналитики) «Событие» с заданными
параметрами (дата, время, координаты и т.п.).
Видеопоток из буфера с отметками (метаданными события)
переносится в архив.
6. Базовые сценарии управления услугой.
6.1. Базовый
сценарий
видеоданных.
смены
периода
архивации
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
Назначение сценария: сценарий описывает порядок изменения периода
архивации по услуге.
Участники сценария: Абонент, Система, камера.
Исходные данные сценария: У абонента подключена услуга «Моя квартира»
и услуга «Моя квартира: видеоархив». У абонента статус аккаунта «активен». У
абонента подключена одна и более камер. Абонент не находится в состоянии
финансовой блокировки.
Критерии успешности сценария: Абоненту удалось изменить период
архивации видеоданных.
Базовые шаги сценария:
6.1.1.
6.1.2.
6.1.3.
6.1.4.
6.1.5.
Абонент авторизуется в личном кабинете ЕЛК
Абонент выбирает вкладку «Моя квартира»
Абонент выбирает подраздел «Управление услугой»
Абонент выбирает подраздел «Управление архивацией»
Абоненту отображается список камер с доступным периодом
архивации на каждой камеры (radio button со значениями 0, 7,
(Стадия 2) до 30 дней)
25
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
6.1.6.
6.1.7.
6.1.8.
6.1.9.
6.1.10.
6.1.11.
6.1.12.
6.1.13.
Абонент выбирает периоды архивации для каждой камеры в
списке.
Абонент может выбрать любой из предложенных периодов
архивации для каждой камеры.
Рядом
с
выбранным
периодом
архивации
отображается
ежемесячная плата за архив на выбранную камеру. Внизу
страницы (например, для ЛК) отображается итоговая ежемесячная
сумма за архив.
Абонент подтверждает выбор услуг и соглашается с итоговой
суммой за архив.
Система выводит сообщение абоненту о стоимости услуги
архивации и количество выбранных камер для архивации.
Абонент подтверждает переход на другой период архивации.
В биллинге делается отметка о начале тарификации услуги
видеоархив по выбранному в п. 6.1.9 тарифу. Биллинг производит
перерасчет за пользование архивом исходя из дней пользования.
Абонент
получает
подтверждение,
что
архивирование
на
выбранный период подключено.
6.1.14.
Альтернативные шаги сценария
6.1.7.
6.1.8.
6.1.9.
6.1.10.
Абонент выбирает периоды архивации 0 дней.
Абонент подтверждает выбор.
Система выводит сообщение о том, что с выбранной камеры,
<указать имя> камеры при выводе сообщения, будет отключен
архив.
Система рассчитывает оставшееся время хранения архива до даты
удаления и сообщает абоненту, что в этот период он сможет
сохранить архив (базовый сценарий 7.4). По окончанию периода
архив будет удален.
6.2. Базовый сценарий настройки уведомлений о событиях
через e-mail (Стадия 2).
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
Назначение сценария: сценарий настройки уведомлений о событиях через
e-mail.
Участники сценария: Абонент, Система.
26
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
Исходные данные сценария: У абонента подключена услуга
Видеонаблюдение.
Критерии успешности сценария: Абонент настроил получение уведомлений
через e-mail и получил тестовое письмо.
Базовые шаги сценария:
6.2.1.
6.2.2.
6.2.3.
6.2.4.
6.2.5.
6.2.6.
6.2.7.
Абонент авторизуется в ЕЛК.
Абонент переходить в раздел «Моя квартира».
Абонент переходит в раздел «Настройка услуги».
Абонент переходит в раздел «Настройка оповещений»
Абонент выбирает настройку e-mail
Абоненту предлагается ввести один или более e-mail.
Абоненту прилагается выбрать события для оповещения на e-mail.
Абонент может задать отправку разных событий на разные e-mailАбонент нажимает «Сохранить»
6.3. Базовый сценарий настройки уведомлений о событиях
через SMS (Стадия 2).
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS и Android на Стадии 1. На Стадии 2 данный сценарий должен
быть реализован в мобильных приложениях для Windows Mobile Phone.
Назначение сценария: сценарий настройки уведомлений о событиях через
SMS.
Участники сценария: Абонент, Система, мобильный телефон абонента.
Исходные данные сценария: У абонента подключена услуга
Видеонаблюдение.
Критерии успешности сценария: Абонент настроил получение уведомлений
через SMS.
Базовые шаги сценария:
6.3.1.
6.3.2.
6.3.3.
6.3.4.
6.3.5.
6.3.6.
6.3.7.
6.3.8.
Абонент авторизуется в ЕЛК.
Абонент переходить в раздел «Моя квартира».
Абонент переходит в раздел «Настройка услуги».
Абонент переходит в раздел «Настройка оповещений»
Абонент выбирает настройку SMS
Абоненту предлагается привязать SMS к услуге.
Абонент переходит в раздел настройки оповещений и выбирает
настройка SMS оповещения
Абоненту предлагается ввести номер телефона.
27
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
6.3.9.
6.3.10.
6.3.11.
Абонент вводит один или более (количество доступных номеров
должно быть определено в тарифах на услугу) номеров телефона в
поле (для поля применяется маска (***)***-**-**), по маске
Система определяет мобильного оператора.
Абоненту прилагается выбрать события для оповещения по SMS.
После подтверждения кода Система выводит сообщение об
успешной активации уведомлений.
6.4. Базовый сценарий настройки уведомлений о событиях
через Push notification (Стадия 2).
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
Назначение сценария: сценарий настройки уведомлений о событиях через
Push notification.
Участники сценария: Абонент, Система, Приложения на мобильном
устройстве.
Исходные данные сценария: У абонента подключена услуга
Видеонаблюдение.
Критерии успешности сценария: Абонент настроил получение уведомлений
через Push notification.
Базовые шаги сценария:
6.4.1.
6.4.2.
6.4.3.
6.4.4.
6.4.5.
Абонент запускает мобильное приложение.
Абонент авторизован в мобильном приложении.
Абонент переходить в раздел «Настройка».
Абонент переходит в раздел настройки оповещений и выбирает
настройку Push notification;
Абоненту прилагается выбрать события для оповещения и вид
отображение событий.
6.5. Базовый
сценарий
управления
мобильными устройствами (Стадия 2).
доверенными
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
28
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
Назначение сценария: сценарий управления доступом с мобильных
устройств к управлению камерами и уведомлений о событиях через Push
notification.
Участники сценария: Абонент, Система, Приложения на мобильном
устройстве.
Исходные данные сценария: У абонента подключена услуга
Видеонаблюдение.
Критерии успешности сценария: Абонент настроил получение уведомлений
через Push notification.
Базовые шаги сценария:
6.5.1.
6.5.2.
6.5.3.
6.5.4.
6.5.5.
6.5.6.
6.5.7.
Абонент авторизован в ЛК.
Абонент переходить в раздел Видеонаблюдение.
Абонент переходит в раздел «Настройка услуги».
Абонент переходит в раздел «Настройка безопасности»
Абонент переходит в раздел «Настройка доступа с мобильных
устройств»
Абоненту выводится список доверенных мобильных устройств.
Абонент может удалить мобильное устройство из списка
доверенных устройств.
6.6. Базовый сценарий управления Услугой с мобильного
устройства
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
Назначение сценария: сценарий описывает порядок управления Услугой
абонентами с мобильного устройства.
Участники сценария: Абонент, Система, Мобильное устройство (планшет или
смартфон).
Исходные данные сценария: У абонента подключены услуги «Моя
квартира».
Критерии успешности сценария: Абонент просматривает изображение с
камер. Может настроить область просмотра. Сделать скриншот изображения с
камеры.
Базовые шаги сценария:
29
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
6.6.1.
6.6.2.
6.6.3.
6.6.4.
6.6.5.
Абонент находит приложение для мобильного устройства в Apple
Store, (Стадия 2) - Google Play Market по ключевому слову или по
ссылке из ЛК/рекламного материала.
Абонент устанавливает приложение на мобильном устройстве.
Абонент авторизуется в приложении под учетной записью ЕЛК.
Мобильное приложение запоминает учетную запись ЕЛК и не
требует повторной авторизации.
К одному ЛК может быть привязано до Х приложений.
7. Базовые сценарии использования услуги
7.1. Базовый сценарий – Просмотр видео изображения с
камер
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
Назначение сценария: сценарий описывает порядок использование услуги
абонентами.
Участники сценария: Абонент, Система.
Исходные данные сценария: У абонента подключены услуги «Моя
квартира».
Критерии успешности сценария: Абонент просматривает изображение с
камер. Может настроить область просмотра. Сделать скриншот изображения с
камеры.
Базовые шаги сценария:
7.1.1.
7.1.2.
7.1.3.
7.1.4.
7.1.5.
7.1.6.
Абонент загружает страничку ЕЛК услуги либо запускает
мобильное приложение
Абонент заходит в раздел просмотра и управления камерами
Под каждой камерой отображается имя камеры, данное ему при
регистрации видеокамеры
Абонент может выбрать из нескольких вариантов расположения
камер в области просмотра камер.
Система должна сохранять расположение изображений с камер в
области просмотра в порядке определенным абонентом.
Абонент видит изображение с выбранных камер.
30
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
7.1.7.
7.1.8.
В области просмотра должна быть возможность перейти в
полноэкранный режим для каждого изображения.
В области просмотра, для каждого изображения, должна быть
предусмотрена возможность сделать скриншот с камеры.
7.2. Базовый сценарий – Просмотр видео изображения в
видеоархиве
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
Назначение сценария: сценарий описывает порядок использование услуги
«Моя квартира (видеоархив)».
Участники сценария: Абонент, Система.
Исходные данные сценария: У абонента подключены услуги «Моя квартира»
и «Моя квартира (видеоархив)».
Критерии успешности сценария: Абонент просматривает изображение в
архиве, с выбранных камер. Может сделать скриншот изображения
видеоархива.
Базовые шаги сценария:
7.2.1.
7.2.2.
7.2.3.
7.2.4.
7.2.5.
7.2.6.
7.2.7.
Абонент загружает страничку ЕЛК услуги, либо запускает
мобильное приложение
Абонент заходит в раздел просмотра видеоархива
Под каждой камерой отображается имя камеры, данное ему при
регистрации видеокамеры
Абонент выбирает дату и время на шкале времени, которое хочет
просмотреть.
Абонент видит архивное изображение с выбранных камер.
В области просмотра должна быть возможность перейти в
полноэкранный режим для каждого изображения.
В области просмотра, для каждого изображения, должна быть
предусмотрена возможность сделать скриншот с просматриваемого
видеоролика.
7.3. Базовый сценарий – Пассивная постановка на охрану
(Стадия 2)
31
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
Назначение сценария: сценарий описывает порядок использование услуги
абонентами.
Участники сценария: Абонент, Система.
Исходные данные сценария: У абонента подключена услуга «Умная
квартира».
Критерии успешности сценария: Абонент может по команде с мобильного
приложения или из ЛК услуги включить/отключить услугу «Пассивная
постановка на охрану». От Системы начинают приходить уведомления о
срабатывании датчика движения.
Базовые шаги сценария:
7.3.1.
7.3.2.
7.3.3.
7.3.4.
7.3.5.
7.3.6.
7.3.7.
7.3.8.
Абонент загружает страничку ЕЛК услуги либо запускает
мобильное приложение
Абонент заходит в раздел просмотра и управления камерами
Под каждой камерой отображается имя камеры, данное ему при
регистрации видеокамеры
Абонент видит список камер. Напротив каждой камеры
отображается статус: “На охране”, “Контроль снят”, “Не доступно”
(офлайн).
Абонент может переключать режимы “На охране” и “Контроль
снят”. Снятие/постановка места на охрану фиксируется в журнале
Услуги.
Абонент получает уведомления настроенные в п.п. 6.2, 6.3, 6.4
Уведомления формируются по детектору движения в соответствии с
индивидуальной настройка камер и режимом “На охране” или
“Контроль снят”. Срабатывания детектора движения фиксируются в
журнале Услуги. Используется встроенный детектор движения
камеры.
Абонент может просмотреть тревожный кадр и/или видео после
уведомления.
7.4. Базовый
сценарий
сохранения
архивированных
видеоданных на внешний носитель (Стадия 2).
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
32
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
Назначение сценария: сценарий описывает порядок сохранения видеоархива
на внешний носитель.
Участники сценария: Абонент, Система, камера, внешний носитель данных.
Исходные данные сценария:
Вариант 1: У абонента подключена услуга «Моя квартира» и услуга «Моя
квартира: видеорхив». У абонента статус аккаунта «активен». У абонента
подключена одна и более камер. Абонент не находится в состоянии
финансовой блокировки.
Вариант 2: У абонента подключена услуга «Моя квартира». У абонента статус
аккаунта «активен». У абонента подключена одна и более камер. Абонент не
находится в состоянии финансовой блокировки. Абонент отключил услугу «Моя
квартира: Архив». У абонента есть Х дней до удаления архива из системы.
Критерии успешности сценария: Абоненту удалось сохранить архив
видеоданных на внешний носитель.
Базовые шаги сценария:
7.4.1.
7.4.2.
7.4.3.
7.4.4.
7.4.5.
7.4.6.
7.4.7.
7.4.8.
Абонент авторизуется в ЕЛК
Абонент выбирает вкладку Видеонаблюдение Архив в услуге «Моя
квартира»
Абонент выбирает дату видеоархива из предложенных событий
Абонент выбирает сохранить выбранное событие
Система предлагает задать начальное и конечное время записи
(максимальное время вычисляется Системой, Абонент может гибко
задать границы сохраняемого видеоизображения)
Система предлагает выбрать путь сохранения на внешний носитель
Система
отображает
процесс
загрузки
архивированного
видеоизображения.
По окончанию загрузки Система выводит сообщение о завершении
загрузки.
8. Отключение услуги через ЛК
8.1. Базовый
сценарий
квартира» (Стадия 2)
отключения
услуги
«Умная
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
Назначение сценария: сценарий описывает порядок отключения услуги
абонентами с подключенной услугой «Умная квартира».
33
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
Участники сценария: Абонент, Система.
Исходные данные сценария: У абонента подключены услуги «Моя квартира»
и «Умная квартира». У абонента есть доступ к ЛК.
Критерии успешности сценария: У абонента отключены выбранные им
услуги.
Ограничения сценария: При отключении услуги «Умная квартира» у
абонента услуга «Моя квартира (видеоархив)» переходит в режим постоянной
записи.
Базовые шаги сценария:
8.1.1.
Абонент загружает страничку ЕЛК или загружает мобильное
приложение
8.1.2.
Абонент авторизуется в личном кабинете
8.1.3.
Абонент выбирает вкладку «Моя квартира»
8.1.4.
Абонент выбирает подраздел «Управление услугой»
8.1.5.
Абонент выбирает «Отключить Умную квартиру»
8.1.6.
Абонент подтверждает выбор отключаемых услуг
8.1.7.
Абонент получает подтверждение, что выбранные услуги
отключены.
8.1.8.
В биллинге отключается тарификация по услуге «Умная квартира».
Альтернативный сценарий:
8.1.9.
Если у Абонента услуга «Моя квартира (видеоархив)» настроена на
видеозапись по сообщениям «Умной квартиры», то услуга «Моя
квартира (видеоархив)» переходит в режим постоянной записи.
8.2. Базовый сценарий отключения услуг «Моя квартира
(видеоархив)»
Данный сценарий должен быть реализован в web-клиенте для РС, мобильных
клиентах для iOS на Стадии 1. На Стадии 2 данный сценарий должен быть
реализован в мобильных приложениях для Android и Windows Mobile Phone.
Назначение сценария: сценарий описывает порядок отключения услуги
«Моя квартира (видеоархив)» абонентами с подключенной услугой «Моя
квартира (видеоархив)».
Участники сценария: Абонент, Система.
Исходные данные сценария: У абонента подключены услуги «Моя квартира
(видеоархив)». У абонента есть доступ к ЛК.
34
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
Критерии успешности сценария: У абонента отключены выбранные им
услуги.
Базовые шаги сценария:
8.2.1.
8.2.2.
8.2.3.
8.2.4.
8.2.5.
8.2.6.
8.2.7.
8.2.8.
8.2.9.
Абонент загружает страничку ЕЛК или загружает мобильное
приложение
Абонент авторизуется в личном кабинете
Абонент выбирает вкладку «Моя квартира»
Абонент выбирает подраздел «Управление услугой»
Абонент
выбирает
отключение
услуги
«Моя
квартира
(видеоархив)»
Абонент подтверждает выбор отключения услуги «Моя квартира:
архив»
Система рассчитывает оставшееся время хранения архива до даты
удаления и сообщает абоненту, что в этот период он сможет
сохранить архив (базовый сценарий 7.4). По окончанию периода
архив будет удален.
Абонент получает подтверждение, что выбранные услуги
отключены.
В биллинге отключается тарификация по услуге «Моя квартира
(видеоархив)».
8.3. Базовый сценарий отключения услуг «Моя квартира»
Назначение сценария: сценарий описывает порядок отключения услуги
«Моя квартира».
Участники сценария: Абонент, Система.
Исходные данные сценария: У абонента подключена услуга «Моя
квартира». У абонента есть доступ к ЛК.
Критерии успешности сценария: У абонента отключены выбранные им
услуги.
Ограничения сценария: При отключении услуги «Моя квартира» у абонента
будут отключены все дополнительные услуги видеонаблюдения.
Базовые шаги сценария:
8.3.1.
8.3.2.
8.3.3.
8.3.4.
8.3.5.
Абонент загружает страничку ЕЛК
Абонент авторизуется в личном кабинете
Абонент выбирает вкладку «Моя квартира»
Абонент выбирает подраздел «Управление услугой»
Абонент выбирает услугу «Моя квартира», которую
отключить
хочет
35
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
8.3.6.
8.3.7.
8.3.8.
Абонент подтверждает выбор отключения услуги
Абонент получает подтверждение, что выбранные услуги
отключены - «Моя квартира», «Моя квартира (видеоархив)»,
«Умная квартира» (Стадия 2).
В биллинге отключается тарификация по всем услугам: «Моя
квартира», «Моя квартира (видеоархив)», «Умная квартира»
(Стадия 2).
9. Требования к тарификации
1. Биллинг должен поддерживать единовременную тарификацию и
ежемесячную периодическую.
2. Абонентская плата за пользование услугой взымается ежемесячно,
начисления должны выставляться в едином счёте.
3. В Биллинге должна быть реализована возможность установки
абонентской платы для каждой услуги.
4. В Биллинге должна быть реализована возможность установки разовых
списаний для каждой услуги.
5. Платежи за основную услугу могут быть только фиксированными
(единовременными и ежемесячными), платежи по объему потребления
(трафиковые) не предусматриваются.
6. Биллинг должен обеспечивать подключение и отключение услуги внутри
расчетного периода.
7. Услуга передачи данных не включена в стоимость услуг ВН и ВА.
8. Для абонентов (пользователей) МГТС, пользующихся основными
услугами (ТВ, Интернет, фиксированный телефон) предоставляется
кредитный метод оплаты.
9. Для абонентов, не являющихся пользователями основных услуг,
используется авансовый метод оплаты (актуально только для B2C). Как
вариант, может быть использован механизм кредитной оплаты с
неснижаемым уровнем депозита на лицевом счете (ЛС) абонента
(Гарантийный взнос).
Перечень услуг
Оплата за услуги
Единовременно
Ежемесячно
Платежи
Периодические
по объему
платежи
/ трафику
«Моя квартира»
+
+
-
«Умная квартира»
+
+
-
36
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
«Моя квартира (видеоархив)»
Сохранение данных с
видеокамер
10.
+
+
+
-
-
-
Базовые требования
10.1. Поддержка абонентов
10.2. Поддержка абонента в Инцидент-менеджмента
Для CallCenter необходимо реализовать в системе Инцидент-менеджмента:






Отображение истории изменений услуги
Детализацию оплаты за платные услуги.
Подключать / Отключать услуги на аккаунт абонента.
Просмотр баланса на аккаунте.
Блокировать / Разблокировать услугу.
Просматривать информацию по не работоспособности услуги.
10.2.1. Дополнительные требования
10.2.2. Со стороны Вычислительного Комплекса должна быть возможность
изменять
настройки
клиентского
оборудования
(Доработка
сервисной платформы), доступ к настройке камер клиента.
10.2.3. Должен быть интерфейс, через который сотрудники компании
могли бы быстро редактировать или загружать текст «Публичной
оферты». Оферта размещается в ЛК Услуги.
11.
Территория предоставления Продукта
11.1.1.
11.1.2.
11.1.3.
Для просмотра камер ограничения по IP нет.
Услуга предоставляется на территории РФ.
Требования к сервису GeoIP
Для запуска услуги Видеонаблюдения, согласно маркетинговым
требованиям, необходимо определять географическую
принадлежность IP адреса, с которого происходит обращение
клиента к сервису. Например, с помощью подключения к базе
http://www.ripe.net/
37
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
1.1
Формат IP адреса на входе GeoIP
IP-адреса в виде четырёх десятичных чисел значением от 0 до 255,
разделённых точками, например, 192.168.0.1.
1.2
Протокол
взаимодействия
между
платформой
Видеонаблюдения и GeoIP
Протокол: HTTP
1.3
Способ передачи данных
На вход GeoIP данные могут передаваться через GET или через
SOAP.
Ответ в виде XML, JSON или просто текст c разделителями.
1.4
Требования к надёжности GeoIP
Доступность: 24х7
Резервный GeoIP: требуется
1.5
Требования к аутентификации
Ограничение только по ACL, список IP-адресов предоставляется
оператором OTT.
1.6
Требование к скорости ответа
Время ответа GeoIP не должно превышать 100 миллисекунд (0.1
секунды).
1.7
Требования к данным в ответе GeoIP
В ответе передаётся принадлежность IP-адреса к России или нет.
Принадлежность IP Адреса
Ответ
Россия
Russia
Все другие страны
World
1.8
Возможность добавлять или выводить IP-сети в/из GeoIP с
присвоением страны
Данная опция требуется, т.к IP-адрес, который будет приходить в
GeoIP в отдельных случаях будет иметь локальный вид, например:
10.х.х.х или 192.168.0.2, что не позволит определить страну.
Время применения изменения не более 24 часов.
1.9
Техническая поддержка сервиса GeoIP:
24х7
1.10 Нагрузочная способность сервиса GeoIP
Пиковая скорость обращения к сервису: 100 вызовов в секунду
Средняя скорость: 10 вызовов в секунду
1.11 Физическое расположение сервиса GeoIP
Вне площадки оператора
38
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
12.
Требования к финансово – юридической схеме Продукта
12.1.1.
12.1.2.
13.
Невозможно подключение Камер без акцепта оферты на
пользование услугой Видеонаблюдения и получения согласия на
хранение, обработку и использование персональных данных.
Потребуется разработка Соглашения об обработке персональных
данных, которое будет заключаться между Компанией и Абонентом
(собственником квартиры).
Требования к отчетности
Требования к отчетности разрабатываются на этапе ОКЭ
В момент запуска в ОКЭ должна быть обеспечена базовая статистика по
услугам и абонентам. Статистическая запись должна содержать следующие
поля:
-
ID учетной записи абонента
Тип бизнеса абонента.
Дата/время запроса
Количеств подключенных услуг у абонентов
Количество подключенных/отключенных модулей аналитики
Доля по времени просмотра (время просмотра камер клиентом)
14.
Требования к бизнес KPI работы Продукта
KPI по продукту, а так же ФТ на формирование показателей и систему
мониторинга работоспособности продукта (в случае, если реализация
мониторинга не повлечет за собой дополнительных затрат) будут разработаны
на этапе разработки;
Пороги согласованы на этапе ОКЭ;
15.
Требования к нагрузке на Продукт
Год
Кол-во абонентов
2014
2015
2016
2017
500
3000
5000
20000
2018
50000
2019
100000
2020
200000
Средняя нагрузка
в течение дня
Пиковая нагрузка
в течение дня
39
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.
16.
Требования к абонентскому оборудованию
16.1. IP видеокамеры
Камеры должны поддерживать как минимум следующий функционал

Тип датчика изображения – прогрессивная развертка, CMOS

Минимальная освещенность работы камеры должна составлять Color: 0.2 lux,
B/W: 0.04 lux.

Должна обеспечивать частоту кадров при максимальном разрешении не
менее 25 кадр/с (для форматов HDTV 720p и 1080p)

Должна обладать механическим инфракрасным фильтром

Видеокамера должна обеспечивать сжатие видеосигнала в кодеках H.264 и
Motion JPEG

Видеокамера должна обеспечивать выполнение следующих
настроек: автоматическое регулирование усиления, настройка зоны
экспозиции, компенсация фоновой засветки, настройка баланса белого,
настройка параметров электронного затвора, фильтр подавления мерцания,
зоны маскирования изображения

Поддержка цифрового PTZ

Поддержка диафрагмы типа Р-Iris (для 2-х и более мегапиксельных
устройств)

Возможность подстройки баланса белого в ручном режиме

Поворот изображения 0°, 90°, 180°, 270°

Зеркальное отображение изображения

Наложение текста и изображений на видео (оверлей)

Multi-view streaming (передача нескольких масштабированных участков
изображения одновременно с общим планом сцены в качестве отдельных
видеопотоков)

Несколько отдельно конфигурируемых видеопотоков в форматах H.264 и
Motion JPEG

Счетчик пикселей выделенной области изображения

Датчик попыток вмешательства в работу камеры

Поддержка режима формирования фиксированного потока данных (CBR) и
переменного (VBR)

Открытый платформо - независимый API интерфейс управления

Поддержка ONVIF profile S

Открытая прикладная платформа для запуска программных приложений
непосредственно в камере (в том числе сторонних производителей)

Возможность записи изображений на несколько FTP серверов одновременно
(не менее двух)
40
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.

В уличном исполнении не менее IP66, NEMA 4X, IK10

Фильтрация IP адресов

Шифрование по протоколу HTTPS

Камера в уличном исполнении комплектуется объективом, термокожухом и
кронштейном (кронштейн в комплекте только для фиксированных моделей)

Поддержка питания по технологии PoE/PoE+, для камер уличного исполнения
при работе до -40/-50 градусов требуется питание PoE+ (для
фиксированных) или PoE 60W (для поворотных).
16.2. Требования к камерам со стороны платформы
подключения и реализации функционала Plug&Play
для
1. Камера должна уметь транслировать видеопоток по протоколу RTSP (Real Time
Streaming Protocol, RFC 2326) с поддержкой:
 Медиаконтента video/h264 в соответствии с RFC 6184 (типы 96, 97).
 Алгоритма сжатия H.264 (ITU-T Recommendation H.264 and the technically
identical ISO/IEC International Standard 14496 part 10).
 Поддерживать, как минимум Baseline - профиль для H264
2. Взаимодействие по протоколу RTSP должно удовлетворять следующим
требованиям:



Типы авторизации: basic authorization, digest authorization;
Методы: OPTIONS, DESCRIBE, SETUP, PLAY.
Обеспечивать получение конфигурационных параметров видеопотока:
разрешение, битрейт, число кадров в секунду.
3. Поддерживать следующие протоколы:




Управляющий протокола SDP.
Прикладные протоколы RTP/AVP, предпочтительно в режиме interleaved.
Транспортный протокол TCP/UDP (рекомендуемый – TCP).
При наличии в камере микрофона или возможности подключению
микрофона через внешние разъемы поддерживать кодек G711
4. Требованию к реализации функционала plug’n’play в камере


Должна быть возможность подержать 2 варианта предпродажной подготовки камер:
Программно-аппаратная платформа имеет SDK для сборки пакетов, которые
инсталлируются и регистрируются в камере, используя API, программная сборка
предоставляет возможность настройки приложения через HTTP.
Приложение вместе с конфигурационным файлом, используя пакет SDK, встраивается в
заводскую прошивку камеры.
Дополнительные требования к SDK:


Должен быть функционал для работы с WiFi сетями с возможностью удаленной настройки.
Должна быть возможности управления скоростью и разрешением видео потока с камеры.
41
ВНИМАНИЕ: если в тексте документа явно не указано, что данная функциональность
относиться к Стадии 2, то данная функциональность должна быть реализована на Стадии
1.


Должна быть возможность поддержки и настройки передачи видеопотока по
защищенному каналу.
Должна быть возможность закрыть функционал камеры от внешних вмешательств
пользователя
16.3. Коммутаторы

Количеств разъемов RJ45 4, 8, 12

Наличие портов RJ45 с поддержкой стандарта PoE/PoE+;

Обеспечивать хорошую производительность при работе с большими потоками
видеоданных;

Обеспечивать высокую скорость восстановления системы после сбоев и
экстренного отключения питания.

Обеспечивать высокую скорость фильтрации и продвижения кадров (830 нс.
для кадра размером 64 байта);

Наличие дополнительных портов с повышенной пропускной способностью.

Поддержка функции loop-protection (желательно)
17.
-
Требование к статистике
17.1. Статистическая запись должна содержать следующие поля:
 ID учетной записи абонента
Тип абонента.
Дата/время запроса
Количеств подключенных услуг у абонентов
Количество подключенных/отключенных модулей аналитики
Доля по времени просмотра (время просмотра камер клиентом);
18. Приложение 1 «Модели пользовательских интерфейсов к
Продукту»
HTML Document
42