Вы можете открыть актуальную версию документа прямо сейчас.
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.
Вход
Приложение
Приложение
к распоряжению Департамента
информационных технологий города Москвы
от 13 ноября 2020 г. N 64-16-613/20
Приложение 2
к распоряжению Департамента
информационных технологий города Москвы
от 31 июля 2015 г. N 64-16-241/15
Регламент
передачи информации об объектах видеонаблюдения в государственную информационную систему "Единый центр хранения и обработки данных" из локальных систем видеонаблюдения
1. Основные положения
1.1. Настоящий Регламент определяет порядок передачи в государственную информационную систему "Единый центр хранения и обработки данных" (далее - ЕЦХД) информации об объектах видеонаблюдения и иной информации (далее - информация) путем подключения к ЕЦХД локальных систем видеонаблюдения органов исполнительной власти города Москвы, подведомственных им организаций и иных лиц (далее - Поставщики информации), а также требования к такой информации и ее составу.
Настоящий Регламент разработан в соответствии с пунктами 18, 19 Положения о государственной информационной системе "Единый центр хранения и обработки данных", утвержденного постановлением Правительства Москвы от 07.02.2012 N 24-ПП "Об утверждении положения о государственной информационной системе "Единый центр хранения и обработки данных" и иными нормативными правовыми актами, регулирующими вопросы, которые затрагиваются настоящим Регламентом.
1.2. В настоящем Регламенте используются следующие термины и определения:
Средство видеонаблюдения - камера видеонаблюдения и/или иное программно-техническое устройство, предназначенное для формирования информации об объекте видеонаблюдения, в том числе видеоизображения объекта видеонаблюдения.
Локальная система видеонаблюдения (далее - ЛСВН) - система видеонаблюдения, совокупность программно-технических средств и программно-аппаратных комплексов, в том числе средств видеонаблюдения, находящихся в ведении Поставщика информации, обеспечивающих получение, обработку и передачу информации об объектах видеонаблюдения.
Подключение ЛСВН к ЕЦХД - комплекс организационных и технических мероприятий, результатом которых является функционирование процесса передачи в ЕЦХД информации, содержащейся в ЛСВН. Подключение ЛСВН к ЕЦХД осуществляется в соответствии с настоящим Регламентом.
Оператор ЕЦХД - Департамент информационных технологий города Москвы (далее - Департамент), Государственное казенное учреждение города Москвы "Московское городское агентство по телекоммуникациям" (в части эксплуатации и иного технического сопровождения ЕЦХД в соответствии с распоряжением Департамента информационных технологий города Москвы от 04.09.2012 N 64-16-749/12).
РГВУ - межведомственная рабочая группа верхнего уровня, постоянно действующий коллегиальный орган, осуществляющий свою деятельность в соответствии с пунктом 13 Положения о государственной информационной системе "Единый центр хранения и обработки данных", утвержденного постановлением Правительства Москвы от 07.02.2014 N 24-ПП "Об утверждении положения о государственной информационной системе "Единый центр хранения и обработки данных", на основании совместного решения Департамента и Департамента региональной безопасности и противодействия коррупции города Москвы о создании такой Рабочей группы верхнего уровня, настоящего Регламента, а также иных правовых актов Департамента. Состав Рабочей группы верхнего уровня может включать в себя служащих отраслевых органов исполнительной власти города Москвы, федеральных органов исполнительной власти и Департамента. Состав Рабочей группы верхнего уровня утверждается совместным решением Департамента и Департамента региональной безопасности и противодействия коррупции города Москвы о создании Рабочей группы верхнего уровня.
РГНУ - межведомственная рабочая группа нижнего уровня по развитию общегородской системы видеонаблюдения под руководством префектуры соответствующего административного округа города Москвы или органа исполнительной власти города Москвы, подведомственной им организации. Составы РГНУ утверждаются на заседании РГВУ. В состав РГНУ могут входить представители отделов по административным округам города Москвы следующих структур: Управления Федеральной службы безопасности Российской Федерации по городу Москве и Московской области, Главного управления Министерства внутренних дел Российской Федерации по городу Москве, Главного управления Министерства Российской Федерации по делам гражданской обороны, чрезвычайным ситуациям и ликвидации последствий стихийных бедствий по городу Москве, Главного управления Федеральной службы войск национальной гвардии Российской Федерации по городу Москве.
2. Подключение ЛСВН к ЕЦХД
2.1. Поставщик информации обеспечивает передачу в ЕЦХД информации из находящихся в его ведении ЛСВН в соответствии с настоящим Регламентом.
2.2. Решение о подключении ЛСВН к ЕЦХД, об отсутствии необходимости или возможности подключения ЛСВН к ЕЦХД, о дооснащении камерами видеонаблюдения ЛСВН, а также переносе существующих камер видеонаблюдения принимает РГВУ, для чего Оператор ЕЦХД направляет соответствующее обращение на имя председателя РГВУ.
2.3. Отдельные вопросы подключения ЛСВН к ЕЦХД могут быть делегированы РГНУ, в исключительных случаях решение о подключении либо об отсутствии необходимости или возможности подключения ЛСВН к ЕЦХД принимается Оператором ЕЦХД.
2.4. Для разрешения вопроса о подключении или об отсутствии необходимости (возможности) подключения ЛСВН к ЕЦХД, дооснащении камерами видеонаблюдения ЛСВН, а также переносе существующих камер видеонаблюдения Поставщик информации оказывает Оператору ЕЦХД необходимое содействие при анализе характеристик ЛСВН Поставщика информации.
2.5. По запросу Оператора ЕЦХД Поставщик информации направляет в срок, не превышающий 30 (тридцати) календарных дней со дня поступления такого запроса:
- фамилии, имена, отчества (при наличии), телефоны, адреса электронной почты работников (служащих) Поставщика информации либо иных лиц, уполномоченных Поставщиком информации взаимодействовать с Оператором ЕЦХД по вопросам подключения ЛСВН к ЕЦХД и эксплуатации ЛСВН в ходе и после ее подключения к ЕЦХД;
- заполненный опросный лист по форме согласно приложению 1 к настоящему Регламенту, содержащий сведения о находящихся в ведении данного Поставщика информации ЛСВН и их составе, информация с которых поступает в ЛСВН (форма опросного листа может быть изменена по решению Оператора ЕЦХД);
- техническую документацию (в случае, если СВН запланирована к установке/модернизации), включающую в себя наименование программно-технических средств и количество единиц оборудования, структурную схему с указанием на ней оборудования видеонаблюдения, способов подключения и каналов связи (включая их технические параметры), ситуационный план с указанием мест размещения камер видеонаблюдения и сцен обзора;
- иную информацию по требованию РГВУ, РГНУ или Оператора ЕЦХД.
2.6. Полученные Оператором ЕЦХД от Поставщика информации сведения о ЛСВН, указанные в пункте 2.5 настоящего Регламента, направляются на рассмотрение РГВУ. По результатам рассмотрения сведений о ЛСВН РГВУ может быть принято одно из следующих решений:
2.6.1. Не производить подключение ЛСВН к ЕЦХД.
2.6.2. Произвести подключение ЛСВН к ЕЦХД, выдать при необходимости Поставщику информации рекомендации по подключению ЛСВН к ЕЦХД, которые могут содержать:
- перечень (количество) камер видеонаблюдения, информация с которых подлежит передаче в ЕЦХД;
- места расположения камер видеонаблюдения (в случае, если требуется установка средств видеонаблюдения);
- рекомендации по смене места расположения установленных камер видеонаблюдения, корректировке зон обзора камер видеонаблюдения;
- тип подключения ЛСВН к ЕЦХД в соответствии с приложением 2 к настоящему Регламенту;
- реестр аппаратных или программных средств видеонаблюдения, которые ранее успешно прошли проверку на совместимость с управляющими системами ЕЦХД в соответствии с приложением 6 к настоящему Регламенту;
- срок хранения архивных данных в ЛСВН (если применимо);
- требование о передаче Оператору ЕЦХД функций управления поворотными камерами видеонаблюдения (при необходимости);
- рекомендуемую техническую схему реализации подключения;
- срок подключения ЛСВН к ЕЦХД;
- иную информацию.
Сведения о принятом решении Оператор ЕЦХД направляет Поставщику информации.
2.7. Для подключения к ЕЦХД ЛСВН должна отвечать требованиям, указанным в приложении 3 к настоящему Регламенту, в соответствии с согласованным типом подключения.
2.8. В случае если принято решение произвести подключение ЛСВН к ЕЦХД, Поставщик информации:
- в соответствии с настоящим Регламентом и рекомендациями по подключению ЛСВН к ЕЦХД осуществляет подключение ЛСВН к ЕЦХД;
- заключает с Оператором ЕЦХД Соглашение о взаимодействии в соответствии с приложением 4 к настоящему Регламенту после завершения подключения ЛСВН к ЕЦХД;
- обеспечивает работоспособность ЛСВН подключенной к ЕЦХД в соответствии с заключенным Соглашением о взаимодействии.
2.9. По согласованию с Оператором ЕЦХД содержание типового Соглашения о взаимодействии может быть изменено.
2.10. Соглашение о взаимодействии является безвозмездным и определяет права и обязанности Поставщика информации, Оператора ЕЦХД при подключении ЛСВН к ЕЦХД и при передаче информации из ЛСВН в ЕЦХД. Соглашение о взаимодействии должно соответствовать нормативным правовым актам города Москвы и Российской Федерации. Одно Соглашение о взаимодействии может быть заключено в отношении нескольких ЛСВН, находящихся в ведении одного Поставщика информации.
2.11. Поставщик информации осуществляет подключение ЛСВН к ЕЦХД, включая организацию и последующее обеспечение функционирования каналов связи, необходимых для подключения ЛСВН к ЕЦХД, технические требования к которым указаны в приложении 5 к настоящему Регламенту, за счет собственных средств. В отдельных случаях по решению РГВУ или Оператора ЕЦХД канал связи может быть организован за счет бюджетных ассигнований, предусмотренных Департаменту законом города Москвы о бюджете города Москвы на соответствующий финансовый год и плановый период на указанные цели.
2.12. В рамках подключения ЛСВН к ЕЦХД Поставщик информации обязан предоставить Оператору ЕЦХД данные для загрузки сведений о ЛСВН в ЕЦХД в виде электронного документа формата XML, шаблон которого предоставляется Оператором ЕЦХД вместе с инструкцией по заполнению.
По решению Оператора ЕЦХД Поставщику информации может быть предоставлен доступ к определенному разделу портала ЕЦХД для автоматического заведения данных о средствах видеонаблюдения ЛСВН в ЕЦХД, а также доступ к собственным средствам видеонаблюдения в ЕЦХД, включающий в себя потоковую информацию, архивную информацию, стоп-кадры без возможности сохранения информации на электронные носители.
3. Проверка подключения ЛСВН к ЕЦХД
3.1. По результатам выполнения организационно-технических и иных мероприятий в рамках подключения ЛСВН к ЕЦХД Оператор ЕЦХД организует проверку состояния подключения ЛСВН к ЕЦХД.
3.2. По результатам проверки подключения ЛСВН к ЕЦХД Оператором ЕЦХД принимается решение о завершении или незавершении подключения ЛСВН к ЕЦХД.
3.2.1. В случае обнаружения недостатков, не позволяющих обеспечить подключение ЛСВН к ЕЦХД и/или не позволяющих обеспечить надлежащее качество передачи видеоинформации в ЕЦХД, Оператор ЕЦХД формирует перечень замечаний и направляет его Поставщику информации. После исправления указанных замечаний осуществляется повторная проверка подключения ЛСВН к ЕЦХД в течение 30 (тридцати) календарных дней.
3.2.2. По результатам успешного подключения ЛСВН к ЕЦХД Оператор ЕЦХД с Поставщиком информации заключает Соглашение о взаимодействии и выдает Поставщику информации Сертификат ЛСВН по форме согласно приложению 7 к настоящему Регламенту. Перечень средств видеонаблюдения, информация с которых поступает в ЕЦХД через ЛСВН, параметры доступа к указанной информации, а также сведения о других параметрах ЛСВН указываются в приложении к Сертификату ЛСВН. При этом Оператором ЕЦХД периодически проводится актуализация ранее выданных Сертификатов ЛСВН.
3.2.3. После получения Сертификата ЛСВН Поставщиком информации ЛСВН признается подключенной к ЕЦХД.
3.3. После завершения подключения ЛСВН к ЕЦХД Поставщик информации обеспечивает в соответствии с настоящим Регламентом и Соглашением о взаимодействии своевременное, надлежащее и качественное предоставление в ЕЦХД содержащейся в ЛСВН информации об объектах видеонаблюдения, а также осуществляет мероприятия по устранению неисправностей процесса передачи информации из ЛСВН в ЕЦХД (при наличии).
3.4. Любые изменения характеристик и условий предоставления информации из подключенной к ЕЦХД ЛСВН в ЕЦХД возможны исключительно по согласованию с Оператором ЕЦХД. Поставщик информации ЛСВН обязан предоставлять Оператору ЕЦХД информацию о планируемых и/или производимых изменениях в характеристиках и условиях предоставления информации из ЛСВН данного Поставщика информации в ЕЦХД, в том числе в целях внесения необходимых корректировок и изменений в Соглашение о взаимодействии.
3.5. В случае неоднократной фиксации Оператором ЕЦХД фактов нарушения требований к объему и качеству информации, подключенной ЛСВН к ЕЦХД, Оператор ЕЦХД имеет право отозвать Сертификат ЛСВН, а также расторгнуть Соглашение о взаимодействии в одностороннем порядке. При отзыве Сертификата ЛСВН считается неподключенной к ЕЦХД.
Приложение 1
к Регламенту передачи информации
об объектах видеонаблюдения
в государственную информационную
систему "Единый центр хранения
и обработки данных" из локальных
систем видеонаблюдения
Сведения
о наличии систем видеонаблюдения на объектах, находящихся в ведении
__ НАИМЕНОВАНИЕ ОРГАНИЗАЦИИ __
Дата заполнения: __.__________ 20__
1. Сводная таблица:
|
N |
Наименование объекта |
Адрес объекта полностью |
Контактное лицо на объекте (ФИО, должность, телефон) |
Видеокамеры |
Видеорегистратор/ Видеосервер (Срок хранения архива (суток)/ Тип/ Марка/ Модель) |
Канал связи (Полный перечень Операторов связи, имеющих точку присутствия на Объекте. Выделить провайдера, который предоставляет связь Вашей организации) |
||||||
|
ВСЕГО |
Из них аналоговые камеры |
Из них цифровые камеры (IP) |
||||||||||
|
Наружной установки, шт. |
Внутри помещения, шт. |
Наружной установки, шт. |
Внутри помещения, шт. |
Наружной установки, шт. |
Внутри помещения, шт. |
Тип, марка, модель |
||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
|
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
|
|
|
2. План объекта:
Предоставляется план Объекта с указанием места размещения и
нанесенным сектором обзора камер (в качестве плана Объекта может быть так
же фрагмент сервиса Яндекс.Карты/Эл. атлас Москвы). Так же может быть
представлена проектная/эксплуатационная документация на систему
видеонаблюдения, содержащая запрашиваемую информацию.
3. Сцены обзора камер:
Предоставляются скриншоты изображений с камер или фотография сцен
обзора камер, сделанные из места их размещения (возможно отклонение точки
съемки от места размещения не далее чем 3 метра).
Примечания:
- идентификаторы (номера) камер на Плане и на скриншотах должны быть
идентичными;
- информация п.п. 2 и 3 оформляется в виде отдельных документов (НЕ
в данной таблице)
- вся информация в электронном редактируемом формате должна быть
направлена в Департамент информационных технологий города Москвы на
адрес: int-video@mos.ru.
Приложение 2
к Регламенту передачи информации
об объектах видеонаблюдения
в государственную информационную
систему "Единый центр хранения
и обработки данных" из локальных
систем видеонаблюдения
Типы подключения локальных систем видеонаблюдения к государственной информационной системе "Единый центр хранения и обработки данных"
1. Перечень терминов, определений и сокращений
|
Сокращение |
Расшифровка |
|
ЛСВН |
Локальная система видеонаблюдения, совокупность программно-технических средств и программно-аппаратных комплексов, в том числе средств видеонаблюдения, находящихся в ведении Поставщика информации, обеспечивающих получение, обработку и передачу информации об объектах видеонаблюдения |
|
Поставщик информации |
Организация, осуществляющая предоставление информации об объектах видеонаблюдения, содержащейся в локальных системах видеонаблюдения организации |
|
ЕЦХД |
Государственная информационная система "Единый центр хранения и обработки данных" |
|
Оператор ЕЦХД |
Департамент информационных технологий города Москвы (далее - Департамент) либо организация, которой по решению Департамента переданы отдельные функции Оператора ЕЦХД |
|
PTZ-управление |
(От англ. Pan, Tilt, Zoom) функции поворота, наклона и масштабирования зоны обзора средства видеонаблюдения |
2. Типы подключения
2.1. Определение типа подключения ЛСВН Поставщика информации к ЕЦХД, а также перечень подключаемых средств видеонаблюдения ЛСВН должно осуществляться по следующим критериям:
- техническая возможность подключения ЛСВН к ЕЦХД;
- экономическая целесообразность мероприятий по подключению;
- функциональные задачи подключения и важность видеоданных, поступающих с ЛСВН.
Выделяются три типа подключения ЛСВН Поставщиков информации к ЕЦХД.
2.1.1. В рамках первого типа подключения ЛСВН Поставщика информации должна обеспечивать трансляцию видеоизображений в режиме реального времени в ЕЦХД. Возможность доступа к трансляции архива, хранение архива, а также выгрузка архива видеоизображений обеспечивается программно-техническими средствами ЕЦХД.
2.1.2. В рамках второго типа подключения ЛСВН Поставщика информации должна обеспечивать возможность трансляции видеоизображений в режиме реального времени в ЕЦХД, а также трансляцию архива и выгрузку архива видеоизображений из ЛСВН Поставщика информации стандартными средствами управляющих систем ЕЦХД. Хранение архива видеоизображений обеспечивается средствами ЛСВН Поставщика информации.
2.1.3. В рамках третьего типа подключения ЛСВН Поставщика информации должна поддерживать трансляцию видеоизображений в режиме реального времени по запросу пользователей в ЕЦХД. Удаленный доступ к трансляции архива, хранение и выгрузка архива видеоизображений средствами ЕЦХД не поддерживаются.
2.2. В рамках каждого типа подключения ЛСВН Поставщиков информации к ЕЦХД возможны два подтипа:
2.2.1. Первый подтип: с поддержкой PTZ-управления камерами видеонаблюдения ЛСВН Поставщика информации средствами ЕЦХД. В этом случае право управления средствами видеонаблюдения ЛСВН будут иметь ограниченный круг пользователей ЕЦХД, по согласованию с Оператором ЕЦХД (по решению Оператора ЕЦХД с управляемых камер видеонаблюдения ЛСВН в ЕЦХД должны передаваться данные телеметрии (PTZ).
2.2.2. Второй подтип: без поддержки PTZ-управления камерами видеонаблюдения ЛСВН Поставщика информации средствами ЕЦХД.
2.3. Удаленный доступ к трансляции архива и (или) выгрузке архива видеоизображений при втором типе подключения ЛСВН Поставщика информации не должен оказывать негативного влияния на трансляцию видеоизображений в режиме реального времени и запись архива.
2.4. В случае обеспечения хранения архива видеоизображений средствами ЛСВН при втором типе подключения срок хранения архива видеоизображений должен составлять не менее 5 (пяти) суток. По решению Оператора ЕЦХД срок хранения архива видеоизображений может быть изменен.
Приложение 3
к Регламенту передачи информации
об объектах видеонаблюдения
в государственную информационную
систему "Единый центр хранения
и обработки данных" из локальных
систем видеонаблюдения
Технические требования
к оборудованию и программному обеспечению в составе локальных систем видеонаблюдения при подключении к государственной информационной системе "Единый центр хранения и обработки данных"
1. Перечень терминов, определений и сокращений
|
Сокращение |
Расшифровка |
|
ЕЦХД |
Государственная информационная система "Единый центр хранения и обработки данных" |
|
Оператор ЕЦХД |
Департамент информационных технологий города Москвы (далее - Департамент) либо организация, которой по решению Департамента переданы отдельные функции Оператора ЕЦХД |
|
Поставщик информации |
Организация осуществляющая предоставление информации об объектах видеонаблюдения, содержащейся в локальных системах видеонаблюдения организации |
|
PTZ-управление |
(От англ. Pan, Tilt, Zoom) функции поворота, наклона и масштабирования зоны обзора средства видеонаблюдения |
|
Авторизация |
Предоставление определенному пользователю информации или группе пользователей прав на выполнение определенных действий, а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий |
|
Оборудование видеонаблюдения |
Программно-техническое устройство (камера видеонаблюдения, видеокодер, видеорегистратор, специализированное программное обеспечение или другое устройство кодирования видеосигнала), обеспечивающее трансляцию видеоизображений в ЕЦХД в требуемом формате |
|
Локальная система видеонаблюдения |
Совокупность программно-технических средств и программно-аппаратных комплексов, в том числе средств видеонаблюдения, обеспечивающих получение и обработку Поставщиком информации сведений об объектах видеонаблюдения (далее - ЛСВН) |
|
HTTP |
(От англ. HyperText Transfer Protocol - протокол передачи гипертекста) протокол прикладного уровня передачи произвольных данных |
|
REST-архитектура |
(От англ. Representational State Transfer - передача состояния представления) архитектурный стиль взаимодействия компонентов распределенного приложения в сети |
|
Интерфейс подключения |
Набор классов, процедур, функций, структур и констант, предназначенный для использования в ЛСВН, и обеспечивающий реализацию взаимодействия ЛСВН с ЕЦХД. Представляет собой набор RSTP-команд и HTTP-запросов, а также определение структуры HTTP-ответов для выражения которых используют форматы XML и/или JSON |
|
ПО |
Программное обеспечение, представляющее собой совокупность программных средств, разработанных ранее и не связанных непосредственно с созданием системы. Обычно общесистемное ПО представляет собой совокупность программ общего назначения, предназначенных для организации вычислительного процесса и решения часто встречающихся задач обработки информации |
|
Порталы ЕЦХД |
Подсистемы портала Оператора ЕЦХД (Технологический портал, ТП) и клиентское ПО ЕЦХД (Пользовательский портал, ПП) |
|
Средство видеонаблюдения |
Камера видеонаблюдения и/или иное программно-техническое устройство, предназначенное для формирования информации об объекте видеонаблюдения, в том числе видеоизображения объекта видеонаблюдения |
|
AAC |
Advanced Audio Coding - многоканальный алгоритм кодирования аудио, поддерживающий потоковую передачу |
|
ACL |
Access Control List - список контроля доступа, который определяет, кто может получать доступ к конкретному объекту и какие именно операции разрешено или запрещено этому субъекту проводить над объектом |
|
API |
Application Programming Interface - интерфейс программирования приложений |
|
CBR |
Constant Bitrate - постоянный битрейт |
|
VBR |
Variable Bitrate - переменный битрейт |
|
HD |
High Definition - видео высокой четкости |
|
ONVIF |
Open Network Video Interface Forum - международный форум, основанный компаниями Axis Communications, Bosch Security Systems и Sony в 2008 году с целью разработки и распространения открытого стандарта для систем сетевого видеонаблюдения |
|
RTP |
Real-time Transport Protocol - протокол транспортного уровня, используется при передаче трафика реального времени. Протокол был разработан Audio-Video Transport Working Group в IETF и впервые опубликован в 1996 году как RFC 1889 и заменен в RFC 3550 в 2003 году |
|
RTSP |
Real Time Streaming Protocol - прикладной протокол, предназначенный для использования в системах, работающих с мультимедиа данными. Протокол разработан IETF в 1998 году и описан в RFC 2326 |
|
RTMP |
Real Time Messaging Protocol - проприетарный протокол потоковой передачи данных, используется для передачи потокового видео и аудиопотоков |
|
SNMP |
Simple Network Management Protocol стандартный интернет-протокол для управления устройствами в IP-сетях на основе архитектур TCP/UDP |
|
TCP/UDP |
Transmission Control Protocol/User Datagram Protocol - протоколы передачи данных |
|
SDK |
Software Development Kit - набор средств разработки |
|
SDP |
Session Description Protocol - сетевой протокол прикладного уровня, предназначенный для описания сессии передачи потоковых данных |
|
SSH |
Secure Shell - сетевой протокол прикладного уровня, позволяющий производить удаленное управление операционной системой и туннелирование ТСР-соединений |
|
Syslog |
System log - стандарт отправки и регистрации сообщений о происходящих в системе событиях, использующийся в IP-сетях |
|
Первый тип интеграции |
Тип интеграции, предусматривающий обеспечение трансляции видеоизображений в режиме реального времени в ЕЦХД, в формате, совместимом с управляющими системами ЕЦХД, и с качеством в соответствии с требованиями Регламента. Возможность доступа к трансляции архива, хранение архива, а также выгрузка архива видеоизображений обеспечивается программно-техническими средствами ЕЦХД |
|
Второй тип интеграции |
Тип интеграции, предусматривающий обеспечение трансляции видеоизображений в режиме реального времени в ЕЦХД, а также трансляцию архива и выгрузку архива видеоизображений из ЛСВН Поставщика информации стандартными средствами управляющих систем ЕЦХД в соответствии с требованиями Регламента. Хранение архива видеоизображений обеспечивается средствами ЛСВН Поставщика информации |
|
Третий тип интеграции |
Тип интеграции, предусматривающий обеспечение трансляции видеоизображений в режиме реального времени по запросу пользователей в ЕЦХД, в формате, совместимом с управляющими системами ЕЦХД, и с качеством в соответствии с требованиями Регламента. Удаленный доступ к трансляции архива, хранение и выгрузка архива видеоизображений средствами ЕЦХД не поддерживаются |
2. Общая схема взаимодействия ЕЦХД с ЛСВН
Общая схема взаимодействия ЕЦХД с ЛСВН приведена на рисунке:
2.1. На основании запроса от Поставщика информации Оператором ЕЦХД может быть организована процедура тестирования оборудования видеонаблюдения с целью определения его совместимости с ЕЦХД.
2.2. Оператор ЕЦХД определяет алгоритм и порядок проведения тестирования:
2.2.1. Тестирование оборудования видеонаблюдения расположенного в тестовой зоне Поставщика информации (здесь и далее в разделе 2 от имени Поставщика информации может так же выступать представитель производителя оборудования видеонаблюдения) (приоритетная схема). В этом случае Поставщик информации организует канал от тестовой зоны до ЕЦХД (в соответствии с требованиями, установленными в приложении 5 к Регламенту), предоставляет техническую документацию к оборудованию видеонаблюдения и оказывает консультационную поддержку. Оператор ЕЦХД проверяет доступность оборудования видеонаблюдения и параметры канала связи. В случае соответствия предъявляемым требованиям, Поставщик информации заполняет форму в виде электронного документа формата XML, шаблон которого предоставляется Оператором ЕЦХД вместе с инструкцией по заполнению. На основании полученных данных Оператор ЕЦХД организовывает подключение тестируемого оборудования видеонаблюдения к тестовой зоне ЕЦХД.
2.2.2. Тестирование оборудования видеонаблюдения в тестовой зоне Оператора ЕЦХД. В этом случае оборудование видеонаблюдения доставляется Поставщиком информации на указанный Оператором ЕЦХД адрес. Поставщик информации предоставляет техническую документацию к оборудованию видеонаблюдения и оказывает консультационную поддержку. Оператор ЕЦХД организовывает подключение тестируемого оборудования видеонаблюдения к тестовой зоне ЕЦХД с использованием электронного документа формата XML, предоставленного Поставщиком информации. По требованию Оператора ЕЦХД Поставщик информации должен предоставить для тестирования также необходимые камеры видеонаблюдения.
2.3. По запросу Поставщика информации Оператор ЕЦХД предоставляет учетные записи для сетевого доступа к тестовой зоне ЕЦХД, а также учетные записи авторизации на тестовых ТП и ПП. Дополнительно могут быть предоставлены учетные записи для сетевого доступа к оборудованию видеонаблюдения. Порядок выдачи учетных записей определяется Оператором ЕЦХД.
2.4. После настройки тестовой зоны и оборудования видеонаблюдения, Оператором ЕЦХД проводятся тестовые испытания в соответствии с приложением 6 к настоящему Регламенту.
2.4.1. По результатам испытаний Поставщику информации направляется заключение о результатах проведенного тестирования.
2.4.1.1. При полном соответствии проверяемых функций оборудование видеонаблюдения признается совместимым с управляющими системами ЕЦХД и вносится в реестр совместимого оборудования, расположенного на ресурсе Оператора ЕЦХД.
2.4.1.2. При частичном соответствии или несоответствии проверяемых функций оборудование видеонаблюдения признается не совместимым с управляющими системами ЕЦХД, Оператор ЕЦХД формирует перечень замечаний и направляет его Поставщику информации.
2.4.1.3. После получения запроса от Поставщика информации, Оператор ЕЦХД проводит повторное тестирование в соответствии с п. 2.4 в течение 30 (тридцать) календарных дней.
2.5. Поставщик информации может предоставить Оператору ЕЦХД SDK оборудования видеонаблюдения, включая имеющиеся библиотеки, техническую документацию и примеры использования для определения Оператором ЕЦХД возможности доработки управляющих систем ЕЦХД в целях подключения оборудования видеонаблюдения.
3. Общие требования к трансляции видеоизображения
ЛСВН должна поддерживать следующие параметры трансляции видеоизображений:
3.1. Передача видеоизображений должна осуществляться по протоколам RTP/RTSP, с учетом дополнений, описанных в данном документе.
3.2. Алгоритм сжатия H.264 (ITU-T Recommendation H.264 and the technically identical ISO/IEC International Standard 14496 part 10).
3.3. Поддерживаемые профили:
- базовый профиль (Baseline Profile) - рекомендуемый;
- основной профиль (Main Profile) без использования b-кадров.
3.4. Режимы передачи видеоизображений:
однопотоковая передача, количество элементарных видеопотоков в рамках одной RTSP сессии не должно превышать 1 (не использовать режим multiple-sliced Н264).
3.5. Захват видео с разрешением не менее HD (1280 x 720). Решение о захвате видео с разрешением менее HD принимает Оператор ЕЦХД.
3.6. Частота кадров - не менее 15 в секунду.
3.7. Поддержка режима формирования фиксированного потока данных (CBR - constant bitrate), переменного (VBR - variable bitrate).
3.8. Наличие в видеопотоке параметров H.264 Sequence Parameters Set/Picture Parameters Set.
3.9. Рекомендуемые параметры битрейта:
- для разрешения HD: постоянный битрейт, настраиваемый в диапазоне от 1 Мбит/с до 2 Мбит/с;
- для разрешения свыше HD: постоянный битрейт, настраиваемый в диапазоне от 2 Мбит/с до 4 Мбит/с или переменный битрейт со сжатием (компрессией) потока в формате Н.264 не более 30%;
- рекомендуется использование constant frame rate;
- рекомендуется использование SE1 с pic_struct для вычисления потокового fps.
3.10. В случае если ЛСВН не поддерживает один из транспортных протоколов (tep/udp), необходимо отдавать 461 ошибку (Unsupported Transport) в ответ на SETUP с неподдерживаемым протоколом.
3.11. Все i-кадры должны помечаться как idr, p-кадры как nonIDR.
4. Требования к формату трансляции видеоизображений
4.1. Формат трансляции видеоизображений должен быть совместим с форматами ЕЦХД и корректно отображаться на порталах ЕЦХД.
4.2. Запрос на получение видеопотока реального времени направляется на средства видеонаблюдения по статичной ссылке, идентификатор камеры видеонаблюдения/канала на сервере должен быть выделен в ссылке отдельным параметром и представлять собой число и/или буквенное значение (rtsp://login:pass@10.10.4.23/ch01, rtsp://login:pass@10.10.4.23/live?id=05 и т.п.) по протоколу RTSP (Real Time Streaming Protocol, RFC 2326) с поддержкой:
- медиаконтента video/h.264 в соответствии с RFC 6184 (типы 96, 97);
- протоколов различного уровня, а именно:
- управляющего протокола SDP;
- прикладных протоколов RTP/AVP, предпочтительно в режиме interleaved;
- транспортных протоколов TCP/UDP (рекомендуемый - TCP);
- RTSP packetization-mode = 0 или 1.
4.3. Последовательность кадров (GOP) в видеопотоке не должна состоять из одних i-кадров, т.е. между i-кадрами обязательно наличие p-кадров.
4.4. Перед каждым i-кадром должны присутствовать sps/pps параметры. Во избежание завышения битрейта потока рекомендуется присылать не более одного sps и pps в GOP-rpynne.
4.5. Взаимодействие по протоколу RTSP осуществляется с поддержкой следующих определений:
- типы авторизации: basic authorization или digest authorization;
- методы: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN, GET_PARAMETER.
4.6. В случае прекращения отправки видеоданных в рамках установленной сессии - в ответ на запрос GET_PARAMETER должна возвращаться ошибка 503 (Service Unavailable).
4.7. Рекомендуется при нехватке ресурсов производительности или недостаточности пропускной способности сети возвращать ошибку 453 (Not Enough Bandwidth).
4.8. В качестве альтернативы к описанным требованиям допускается использование проприетарных протоколов различного уровня, атрибутов и определений, совместимых с компонентами подсистем ЕЦХД.
4.9. В отдельных случаях, по решению Оператора ЕЦХД, для трансляции видеоизображений может быть организовано взаимодействие по протоколу RTMP. В данном случае технические требования к организации такого взаимодействия выдаются Оператором ЕЦХД по запросу от Поставщика информации.
5. Требования к формату трансляции видеоизображений при работе с локальным архивом видеоизображений
5.1. ЛСВН должна поддерживать возможность одновременной трансляции не менее 30% потоков архивов видеоизображений от общего числа видеопотоков, передаваемых в ЕЦХД с ЛСВН, в случае трансляции локального архива видеоизображений для второго типа подключения ЛСВН. При этом должна быть обеспечена одновременная трансляция не менее 120% видеопотоков в режиме реального времени (100% посредством порталов ЕЦХД, 20% - с использованием сторонних медиапроигрывателей). Превышение указанных показателей не должно приводить к деградации локальной работы оборудования видеонаблюдения и может влиять только на трансляцию в ЕЦХД.
5.2. Запрос на получение информации об объекте видеонаблюдения в режиме доступа к архиву направляется на средства видеонаблюдения по статичной ссылке, идентификатор камеры/канала на сервере должен быть выделен в ссылке отдельным параметром и представлять собой число и/или буквенное значение (например, rtsp://login:pass@10.10.4.23/ch01, rtsp://login:pass@10.10.4.23/archive?id=05 и т.п.) по протоколу RTSP (Real Time Streaming Protocol, RFC 2326) с поддержкой:
- медиаконтента video/h.264 в соответствии с RFC 6184 (типы 96, 97);
- протоколов различного уровня, а именно:
- управляющего протокола SDP в соответствие с RFC 4566;
- прикладных протоколов RTP/AVP в соответствие с RFC 3550, предпочтительно в режиме interleaved;
- транспортных протоколов TCP/UDP (рекомендуемый - TCP);
- RTSP packetization-mode = 0 или 1.
5.3. Последовательность кадров (GOP) в видеопотоке не должна состоять из одних i-кадров, т.е. между i-кадрами обязательно наличие p-кадров при Scale = 1.
5.4. Перед каждым i-кадром должны присутствовать sps/pps параметры. Во избежание завышения битрейта потока рекомендуется присылать не более одного sps и pps в GOP-rpynne.
5.5. При Scale <= -1 отсутствие p-кадров обязательно.
5.6. Разница между кадрами по времени при Scale = 1 должна быть аналогична разнице при Scale = -1.
5.7. ЛСВН должна выполнять прореживание видеопотока при использовании функций перемотки для снижения битрейта и, следовательно, чрезмерной нагрузки на сеть передачи данных. Рекомендуется при Scale > 4 отдавать видеопоток только i-кадрами, а также:
- при перемотке изменение timestamp не должно происходить в отрицательную сторону, а также не должно происходить существенное изменение timestamp - например, более чем на 2000 миллисекунд (в измерительной базе 1 KHz timebase);
- при перемотке на Scale > 4 рекомендуется дополнительно прореживать i-кадры, в случае если битрейт становится больше, чем при Scale = 4;
- при перемотке на Scale: N разница между кадрами по времени должна сократиться в N раз, скорость передачи видеопотока должна возрасти в N раз (для N не более 4). Скорость передачи видеопотока должна соответствовать временным меткам;
- при перемотке на Scale: N разница между i-кадрами по времени должна сократиться в N раз (для N более 4), скорость передачи видеопотока должна соответствовать временным меткам.
5.8. Взаимодействие по протоколу RTSP осуществляется с поддержкой следующих определений:
- типы авторизации:
- Basic authorization или Digest authorization;
- методы:
- OPTIONS - не обязателен.
Пример диалога:
OPTIONS rtsp://10.10.14.41:560/13 RTSP/1.0
CSeq: 1
User-Agent: IStream_vl.9
RTSP/1.0 200 OK
CSeq: 1
Date: Fri, May 20 2016 06:30:11 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER;
- DESCRIBE - обязателен и должен возвращать SDP (время получения ответных данных - не более чем 10 с) при наличии запрашиваемого контента и заголовок User-Agent с реальным значением конкретного видеорегистратора (видеосервера);
Пример диалога:
DESCRIBE rtsp://172.16.1.193:554/camera/playarchive?channel=0 RTSP/1.0
Accept: application/sdp
User-Agent: is3
CSeq: 1
RTSP/1.0 200 OK
CSeq: 1
Server: DH RTSP Server/1.0.1
User-Agent: DH RTSP Server
Date: Mon, 23 May 2016 06:45:04 GMT
Content-Type: application/sdp
Content-Base: rtsp://l 72.16.1.193/playarchive?channel=0
Content-Length: 353
v=0
o=StreamingServer 3433055887 1464007504079164 IN IP4 172.16.1.193
s=playarchive?channel=0
e=NONE
c=IN IP4 0.0.0.0
t=0 0
m=video 0 RTP/AVP 96
b=AS:70
a=control:trackID=1
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4d001e; packetization-mode=1; sprop-parameter-sets=Z00AHpWoLASZ,aO48gA==
a=range:clock=20160522T080352Z-20160523T064503Z;
- SETUP - обязателен.
Пример диалога:
SETUP rtsp://172.16.1.193:554/playarchive/trackID=1?channel=0 RTSP/1.0
User-Agent: is3
CSeq: 2
Transport: RTP/AVP/TCP;interleaved=0-1;unicast
RTSP/1.0 200 OK
CSeq: 2
Server: DH RTSP Server/1.0.1
User-Agent: DH RTSP Server
Date: Mon, 23 May 2016 06:45:04 GMT
Session: 7042370322870790097;timeout=90
Transport: RTP/AVP/TCP;unicast;source=172.16.1.193;interleaved=0-1;ssrc=2ab89ad6;
- PLAY - обязателен, управляющие заголовки:
- Range = "Range" "clock" "=" "utc";
- Scale = "Scale" ":" ["-"] 1*DIGIT ["." *DIGIT] - направление и масштаб скорости воспроизведения, изменяемый на стороне видеорегистратора (видеосервера):
- значение Scale в диапазоне [-32; 32] - ускоренное воспроизведение (рекомендуемые значения |2|, |4|, |6|, |8|, |16|, |32|);
- значение Scale не более -1 - реверс;
- trick play с заголовком/методикой Speed - не должен использоваться и не поддерживается.
Пример диалога:
PLAY при Scale = 1
PLAY rtsp://172.16.1.193:554/playarchive?channel=0 RTSP/1.0
Range: clock=20160522T080352Z-
User-Agent: is3
CSeq: 3
Scale: 1
Session: 7042370322870790097
RTSP/1.0 200 OK
CSeq: 3
Server: DH RTSP Server/1.0.1
User-Agent: DH RTSP Server
Date: Mon, 23 May 2016 06:45:04 GMT
Scale: 1.000000
Range: clock=20160522T080352Z-20160522T082838Z
Session: 7042370322870790097
RTP-Info: url=rtsp://l 72.16.1.193/playarchive?channel=0
-PLAY при Scale = -1
PLAY rtsp://172.16.1.193:554/playarchive?channel=0 RTSP/1.0
Range: clock=-20160523T051954Z
User-Agent: is3
CSeq: 6
Scale: -1
Session: 4483199701296919093
RTSP/1.0 200 OK
CSeq: 6
Server: DH RTSP Server/1.0.1
User-Agent: DH RTSP Server
Date: Mon, 23 May 2016 05:37:45 GMT
Scale: -1.000000
Range: clock=20160523T050207Z-20160523T051954Z
Session: 4483199701296919093
RTP-Info: url=rtsp://172.16.1.193/playarchive?channel=0;
- PAUSE - обязателен.
Пример диалога:
PAUSE rtsp://10.208.14.41:560/archive?id=7_924/ RTSP/1.0
User-Agent: is3
CSeq: 16
Session: F8860AA5
RTSP/1.0 200 OK
CSeq: 15
Date: Fri, May 20 2016 07:30:59 GMT
Session: F8860AA5
Content-Length: 32
Range: clock=20160519T045745Z-;
- TEARDOWN - обязателен.
Пример диалога:
TEARDOWN rtsp://l72.16.1.193:554/playarchive?channel=0 RTSP/1.0
User-Agent: is3
CSeq: 20
Session: 4483199701296919093
RTSP/1.0 200 OK
CSeq: 20
Date: Mon, 23 May 2016 05:38:15 GMT;
- GET_PARAMETER - обязателен, параметр в теле запроса:
position.
В ответ в заголовке должен содержаться Range:clock - текущее абсолютное время воспроизведения, должно соответствовать метке потока, в том числе если она продублирована наложением в самом кадре.
Формат:
Range: clock=20130823T020000Z.
Пример диалога:
GET_PARAMETER rtsp://172.16.1.193:554/playarchive?charmel=0 RTSP/1.0
CSeq: 7
Session: 4483199701296919093
position
RTSP/1.0 200 OK
CSeq: 7
Range: clock=20160523T051935Z
Session: 4483199701296919093.
5.9. Расширение к базовому взаимодействию SDP:
- управление треками согласно протоколу;
- URL трека не может меняться в рамках сессии;
- обязательные атрибуты:
- все доступные типы медиа потоков с указанием протокола и типа данных, например, m=video 0 RTP/AVP 97;
- в случае, если поток динамический, то типы медиа потоков (в соответствии с RFC 6184 (типы 96, 97) должны указываться через атрибут rtpmap, например a=rtpmap:96 H264/90000 и fmtp (с указанием packetization mode [none-interleaved], proftle-level-id, sprop-parameters-set), например a=fmtp:96 packetization-mode=1; proftle-level-id=420029; sprop-parameter-sets=Z0IAKeKQFgJNgScFAQXh4kRU,aM48gA==.
Принят следующий метод информирования о доступных границах воспроизведения в рамках атрибута/поля range протокола SDP:
a=range:clock=20130823T020000Z-20130823T201228Z. Данное поле должно приходить в ответе на DESCRIBE.
Range-сегменты архива должны идти по возрастанию, не допускается наличие сегмента архива за более поздний или аналогичный период чем в следующем сегменте архива. Пример некорректной формы записи: clock=20140823T020000Z-20140823T201228Z; clock=20130904T134708Z-20130904T135513Z (первый сегмент за более поздний период, чем период следующего сегмента - что не верно) или clock=20160421T154212Z-20160421T154434Z; clock=20160421T154434Z-20160421T154444Z (конец первого сегмента совпадает с началом следующего сегмента - что не верно). Если начало нового сегмента, аналогично окончанию предыдущего, необходимо объединять такие сегменты в один. Требуемое число сегментов не более 100 шт. Если сегментов больше, то при работе в рамках RTSP необходимо объединять несколько наиболее близких сегментов в один, таким образом количество сегментов снизится. При попытке позиционирования на несуществующую часть - необходимо позиционировать на следующий ближайший доступный момент времени.
В случае если запись архива не является целостной (имеет разрывы) в виде ряда значений, например:
a=range: clock-20130823T020000Z-20130823T201228Z; clock=20130904T134708Z-20130904T135513Z
или
a=range:cJock=20130823T020000Z-20130823T201228Z; clock=20130904T135808Z-,
где:
- range-список доступных сегментов;
- clock - доступный сегмент, в формате "startUTC-endUTC", может быть открытым, если конечная точка еще не известна.
5.10. В случае если параметр Range:clock из запроса PLAY не воспринимается (не поддерживается) видеорегистратором или ЛСВН - необходимо передавать в ответ 451 код ошибки (451 Parameter Not Understood), при этом воспроизведение должно продолжаться.
Примечание: range:clock в запросе PLAY обязателен, 451 код используется для параметра "-". Например, при отправке PLAY и scale-2 отправляется Range. clock=-20160523T051954Z. Если вернется код 451, то повторно отправится в формате Range: clock=20160523T051954Z-.
По умолчанию отправляется следующий формат:
- при отправке PLAY и scale -1 отправляется Range: clock=-20160523T051954Z;
- при отправке PLAY и Scale 1 отправляется Range: clock=20160522T080352Z-.
5.11. Рекомендуется при нехватке ресурсов производительности или недостаточности пропускной способности сети возвращать ошибку 453 (Not Enough Bandwidth).
5.12. В ответах на запросы должно присутствовать обязательное поле Cseq, которое определяет порядковый номер запроса RTSP. Номер Cseq в ответе должен соответствовать номеру Cseq в запросе.
5.13. SDP диалог должен осуществляться в UTF-8 кодировке.
5.14. В качестве альтернативы к описанным требованиям допускается использование проприетарных протоколов различного уровня, атрибутов и определений, совместимых с компонентами подсистем и видеоядра ЕЦХД.
6. Требования по подключению к средствам видеонаблюдения
6.1. ЛСВН должна поддерживать следующие функции подключения к средствам видеонаблюдения и обеспечивать:
- подключение к средствам видеонаблюдения по протоколу IPv4;
- защищенное подключение к средствам видеонаблюдения посредством выделенных каналов связи, организации виртуальных частных сетей и/или с использованием протоколов ACL, SSH, HTTPS и др.;
- журналирование следующих действий пользователей:
- авторизация пользователя;
- изменение пользователем конфигурационных параметров ЛСВН и подключенных к ней средств видеонаблюдения СВН;
- доступ к архиву видеоизображений;
- поддержка отправки служебных сообщений/событий в открытых протоколах (Syslog, SNMP и прочее).
6.2. Требования к средствам видеонаблюдения, обеспечивающим передачу видеоизображений типа полусфера в форме одной азимутальной проекции:
- средство видеонаблюдения должно быть направлено вертикально вниз;
- центр изображения должен совпадать с центром видимой области; не должно быть геометрических искажений (отклонений от азимутальной проекции);
- масштаб должен быть одинаковым для ширины и высоты изображения;
- размер изображения по ширине и высоте изображения должен быть равен размеру кадра;
- спроецированное изображение не должно изменять азимут направленности.
Требования к средствам видеонаблюдения, обеспечивающим передачу видеоизображений типа сферическая панорама в эквидистантной проекции:
- не должно быть геометрических искажений (отклонений от эквидистантной проекции);
- "верх", "низ", "право" и "лево" спроецированного изображения должно соответствовать положению камеры видеонаблюдения в пространстве;
- спроецированное изображение должно занимать весь кадр;
- спроецированное изображение не должно изменять азимут направленности.
6.3. В части требования к средствам видеонаблюдения со звуком, гарантирована работа только с кодеком ААС частотой 48 кГц.
7. Требования для функции PTZ-управления
7.1. ЛСВН должна поддерживать следующие функции контроля управления средствами видеонаблюдения:
7.1.1. Удаленное управление PTZ - управление функциями средства видеонаблюдения (относительное и абсолютное перемещение влево/вправо/вниз/вверх, увеличение/уменьшение сцены обзора).
7.2. ЛСВН должна поддерживать управление PTZ-функциями устройств пользователями ЕЦХД и пользователями ЛСВН.
7.3. ЛСВН должна обеспечивать следующие функции управления средством видеонаблюдения при условии их поддержки средством видеонаблюдения:
- установка сцены обзора по координатам;
- получение телеметрии средства видеонаблюдения;
- фокусировка (реализуется по требованию Оператора ЕЦХД);
- управление диафрагмой (реализуется по требованию Оператора ЕЦХД);
- ночной режим (реализуется по требованию Оператора ЕЦХД);
- инфракрасный режим (реализуется по требованию Оператора ЕЦХД);
- увеличение/уменьшение чувствительности матрицы (ИК-подсветка) (реализуется по требованию Оператора ЕЦХД);
- черно-белый режим (реализуется по требованию Оператора ЕЦХД).
7.4. ЛСВН должна подтверждать получение команд на PTZ-управление средством видеонаблюдения.
8. Функциональные требования к пользовательскому интерфейсу ЛСВН
8.1. ЛСВН должны предоставлять интерфейс управления, основанный на открытых платформонезависимых стандартах, и поддерживать необходимые программные возможности подключения в зависимости от типа доступа.
8.2. В рамках первого и третьего типов подключения ЛСВН к ЕЦХД должно быть обеспечено выполнение следующих функций:
- получение информации о наличии трансляции видеоизображений с определенного средства видеонаблюдения;
- получение конфигурационных параметров трансляции видеоизображений для определенного средства видеонаблюдения (разрешение, битрейт, число кадров в секунду);
- трансляция видеоизображений с определенного средства видеонаблюдения.
8.3. В рамках второго типа подключения ЛСВН к ЕЦХД должно быть обеспечено выполнение следующих функций:
- получение информации о наличии трансляции видеоизображений с определенного средства видеонаблюдения;
- получение конфигурационных параметров трансляции видеоизображений для определенного средства видеонаблюдения (разрешение, битрейт, число кадров в секунду);
- трансляция видеоизображений с определенного средства видеонаблюдения;
- получение от оборудования видеонаблюдения информации о версии установленного встроенного программного обеспечения;
- получение от оборудования видеонаблюдения информации о работоспособности средства видеонаблюдения;
- получение от оборудования видеонаблюдения информации о наличии архива видеоизображений для определенного средства видеонаблюдения за определенный период;
- трансляцию архива видеоизображений с определенного средства видеонаблюдения с определенного периода времени;
- предоставление архива видеоизображений архива с определенного средства видеонаблюдения за определенный период.
9. Требования для функций передачи геоданных
Целесообразность передачи геоданных со средств видеонаблюдения Поставщика информации определяется Оператором ЕЦХД. Требования к функциям передачи геоданных предоставляются Оператором ЕЦХД по запросу Поставщика информации.
10. Спецификация интерфейса подключения ЛСВН к ЕЦХД
Со стороны ЛСВН должны быть реализованы средства взаимодействия на основе протокола HTTP по технологии "клиент - сервер". Средства взаимодействия должны поддерживать REST-архитектуру. Обмен данными должен производиться в форматах: JSON, XML. Средства взаимодействия в соответствии с типом подключения должны реализовывать методы со следующими сигнатурами:
10.1. Параметры камеры.
GetDevicelnfo ()
Возвращает информацию об устройстве, такую как версия прошивки, название производителя, наименование модели и серийный номер.
Пример:
|
Запрос |
GET http://device-address/getdeviceinfo |
|
Ответ |
{ |
|
"firmware_version": "1.2.3 Rev B.", | |
|
"vendor": "Vendor Title Ltd" | |
|
"model": "Device Model", | |
|
"serial_number": "12345ABCDEF", | |
|
"ptz-status": "not supported" | |
|
} |
10.2. Диапазоны доступных архивных записей.
GetArchiveRanges (CameraId).
Возвращает периоды времени, за которое доступны архивные записи с указанного средства видеонаблюдения. В заголовках ответа необходимо наличие поля "Content-Type: application/json".
Пример:
|
Запрос |
GET http://device-address:80/getarchiveranges?cameraid=1 |
|
Ответ |
{ |
|
"cameraid": 1, | |
|
"ranges": [ | |
|
{ | |
|
"from": 1412121600, //unixtime | |
|
"to": 1412172000 | |
|
}, | |
|
{ | |
|
"from": 1412186400, | |
|
"to": 1412188200 | |
|
} | |
|
] | |
|
} |
10.2.1. GetArchiveUrl (CameraId, FromDatetime, ToDatetime).
Возвращает rtsp URL архивного видеопотока, отдаваемого регистратором, для указанной камеры, начиная с FromDateTime (и опционально, заканчивая EndDateTime). В заголовках ответа необходимо наличие поля "Content-Type: application/json".
Пример:
|
Запрос |
GET http://device-address:80/getarchiveurl?cameraid=1&fromdatetime=2019-10-01T00:00:00&todatetime=2019-10-01T01:20:05 |
|
Ответ |
{ |
|
"rtspurl": "rtsp://device-address:80/somearchivemediastream" | |
|
} |
10.3. Выгрузка архивов.
Выгружаемые архивы должны соответствовать следующим требованиям:
- формат: H.264, MPEG-4 Part 10;
- должен использоваться медиаконтейнер mp4;
- выгруженный архив должен быть упакован в один видеофайл;
- должна обеспечиваться возможность выгрузки архива длительностью не более 12 ч.;
- должна обеспечиваться возможность одновременного выполнения нескольких заданий на выгрузку архивов с ЛСВН (не менее 5% от общего числа видеопотоков, передаваемых в ЕЦХД с ЛСВН, но не менее двух заданий);
- должна обеспечиваться возможность постановки заданий на выгрузку архивов в очередь на выполнение. Размер очереди на количество заданий должен быть не менее, чем 100 x количество поддерживаемых потоков на ЛСВН;
- должен быть обеспечен прием запросов на 80 порт или иной порт по требованию Оператора ЕЦХД.
ЛСВН должна поддерживать один из следующих механизмов выгрузки архивов:
- рекомендуемая выгрузка архивов при помощи методов:
"CreateArchiveTask", "GetArchiveTaskStatus", "RemoveArchive";
- опциональная выгрузка архивов при помощи метода: "DownloadArchiveFile" по согласованию с Оператором ЕЦХД.
10.3.1. Выгрузка архивов при помощи методов CreateArchiveTask, GetArchiveTaskStatus, RemoveArchive.
Выгрузка архивов при помощи следующих методов, описанных ниже:
- создание задания на выгрузку архива;
- получение статуса готовности задания на выгрузку архива;
- удаление архива.
10.3.1.1. Создание задания на выгрузку архива.
Создание задания на выгрузку архива должно выполняться по протоколу HTTP при помощи метода POST.
Наименование метода - CreateArchiveTask.
Для корректной работы метод должен получать следующие данные.
- CameraId - идентификатор камеры (тип данных: "String");
- From - дата и время начала архива (тип данных: "DateTime" в формате YYYY-MM-DDThh:mm:ssZ. Передается время UTC. Пример: 2016-06-20T09:10:12Z - 20 июня 2016 года 12 часов 10 минут 12 секунд по московскому времени);
- To - дата и время окончания архива (тип данных: "DateTime" в формате YYYY-MM-DDThh:mm:ssZ. Передается время UTC. Пример: 2016-06-20T09:10:12Z - 20 июня 2016 года 12 часов 10 минут 12 секунд по московскому времени);
- ответ от метода:
- CameraId - идентификатор камеры (тип данных: "string");
- From - дата и время начала архива (тип данных: "DateTime" в формате YYYY-MM-DDThh:mm:ssZ. Передается время UTC. Пример: 2016-06-20T09:10:12Z - 20 июня 2016 года 12 часов 10 минут 12 секунд по московскому времени);
- To - дата и время окончания архива (тип данных: "DateTime" в формате YYYY-MM-DDThh:mm:ssZ. Передается время UTC. Пример: 2016-06-20T09:10:12Z - 20 июня 2016 года 12 часов 10 минут 12 секунд по московскому времени);
- ArchlveTaskld - идентификатор созданного задания на выгрузку архива (тип данных: "Guid");
- State - статус результата выполнения задачи (тип данных: "String". Один из следующих статусов: "Created", "Error");
- ErrorMessage - сообщение с информацией об ошибке. Заполняется если значение state равно "Error" (тип данных: "String").
Пример запроса CreateArchiveTask:
|
Запрос |
POST http://device-adress:80/createarchivetask HTTP/1.1 |
|
Accept: application/json | |
|
Content-Type: application/json | |
|
Host: device-adress:80 | |
|
Content-Length: 100 | |
|
| |
|
{ | |
|
"CameraId": "2", | |
|
"From": "2016-06-20T09:27:39.984Z", | |
|
"To": "2016-06-20T09:27:39.984Z" | |
|
} | |
|
Ответ |
HTTP/1.1 200 OK |
|
Content-Type: application/json; charset=utf-8 | |
|
Content-Length: 167 | |
|
| |
|
{ | |
|
"CameraId": "2", | |
|
"From":"2016-06-20T09:27:39.984Z", | |
|
"To":"2016-06-20T09:27:39.984Z", | |
|
"ArchiveTaskld":" 1250b5ca-3e74-40cb-9f54-374dfd5050e5", | |
|
"ErrorMessage":null, | |
|
"State": "Created" | |
|
} |
10.3.1.2. Получение статуса готовности задания на выгрузку архива.
Получение статуса готовности задания на выгрузку архива должно выполняться по протоколу HTTP при помощи метода GET.
Наименование метода - GetArchiveTaskStatus.
Для корректной работы метод должен получать следующие данные:
- ArchiveTaskld - идентификатор задания на выгрузку архива (тип данных: "Guid");
Ответ от метода:
- Percents - процент выполнения задания на выгрузку архива (тип данных: "String");
- Url - ссылка на сформированный архив (тип данных: "String");
- Camerald - идентификатор камеры (тип данных: "String");
- From - дата и время начала архива (тип данных: "DateTime" в формате YYYY-MM-DDThh:rnm:ss+/-hh:mm. Передается время с указанием смещения относительно всемирного времени. Пример: 2016-06-20Т08:10:12+03:00 - 20 июня 2016 года 11 часов 10 минут 12 секунд по московскому времени);
- To - дата и время окончания архива (тип данных: "DateTime" в формате YYYY-MM-DDThh:mm:ss+/-hh:mm. Передается время с указанием смещения относительно всемирного времени. Пример: 2016-06-20T08:10:12+03:00 - 20 июня 2016 года 11 часов 10 минут 12 секунд по московскому времени);
- ArchiveTaskId - идентификатор задания на выгрузку архива (тип данных: "Guid");
- ErrorMessage - сообщение с информацией об ошибке. Заполняется если значение state равно "Error" (тип данных: "String");
- State - статус готовности выполнения задачи (тип данных: "String". Один из следующих статусов: "Working", "ReadyForDownload", "Error").
Пример запроса GetArchiveTaskStatus:
|
Запрос |
GET http://device-adress:80/getarchivetaskstatus?archivetaskid=00000000-0000-0000-0000-000000000001 HTTP/1.1 |
|
Ответ |
HTTP/1.1 200 OK |
|
Content-Type: application/json; charset=utf-8 | |
|
Content-Length: 222 | |
|
| |
|
{ | |
|
"Percents": "100", | |
|
"Url": "http://device-adress/1.mp4", | |
|
"Camerald":"2", | |
|
"From":"2016-06-20T08:00:00+03:00", | |
|
"To":"2016-06-20T14:00:00+03:00", | |
|
"ArchiveTaskld": "00000000-0000-0000-0000-000000000001", | |
|
"ErrorMessage":null, | |
|
"State":"ReadyForDownload" | |
|
} |
10.3.1.3. Получение файла архива.
Получение файла архива должно выполняться по протоколу HTTP при помощи метода GET.
Пример запроса:
|
Запрос |
GET/1.mp4 HTTP/1.1 |
|
Host: device-adress | |
|
Accept: text/html.application/xhtml+xml.application/xml;q=0.9,image/webp.*/*;q-0.8 | |
|
Accept-Encoding: gzip, deflate, sdcli | |
|
Ответ |
HTTP/1.1 200 OK |
|
Content-Type: application/octet-stream | |
|
Accept-Ranges: bytes | |
|
Content-Length: 18601634 | |
|
| |
|
Заказанный архив в виде бинарных данных |
10.3.1.4. Удаление архива.
Удаление архива должно выполняться по протоколу HTTP при помощи метода DELETE.
Наименование метода - RemoveArchive.
Для корректной работы метод должен получать следующие данные:
- ArchiveTaskld - идентификатор задания на выгрузку архива (тип данных: "Guid").
Ответ от метода:
- ArchiveTaskld - идентификатор задания на выгрузку архива (тип данных: "Guid");
- Success - признак успешного удаления архива (тип данных: "Boolean");
- ErrorMessage - сообщение об ошибке, в случае если архив не был удален (тип данных: "String").
Пример запроса RemoveArchive:
|
Запрос |
DELETE http://device-adress:80/removearchive?archivetaskid=00000000-0000-0000-0000-000000000001 HTTP/1.1 |
|
Accept: application/json, application/xml, text/json, text/x-json, text/javascript. text/xml | |
|
Host: device-adress:80 | |
|
Accept-Encoding: gzip, deflate | |
|
Ответ |
HTTP/1.1 200 OK |
|
Content-Type: application/json; charset=utf-8 | |
|
| |
|
{ | |
|
"ArchiveTaskld": "00000000-0000-0000-0000-000000000001", | |
|
"ErrorMessage":null, | |
|
"Success":true | |
|
} |
Общая схема, иллюстрирующая работу методов CreateArchiveTask, GetArchiveTaskStatus, RemoveArchive, представлена ниже:
10.3.2. Выгрузка архивов при помощи метода DownloadArchiveFile.
При использовании данного метода в ЛСВН должны быть переданы следующие данные:
- Camerald - идентификатор камеры (тип данных: "string");
- FromDatetime - дата и время начала архива (тип данных: "DateTime" в формате YYYY-MM-DDThh:mm:ss. Передается московское время без указания разности со всемирным временем. Пример: 2016-06-20T09:10:12 - 20 июня 2016 года 9 часов 10 минут 12 секунд по московскому времени);
- ToDatetime - дата и время начала архива (тип данных: "DateTime" в формате YYYY-MM-DDThh:mm:ss. Передается московское время без указания разности со всемирным временем. Пример: 2016-06-20T09:10:12 - 20 июня 2016 года 9 часов 10 минут 12 секунд по московскому времени).
Ответ от метода: видеофайл с архивом.
Общая схема, иллюстрирующая работу метода DownloadArchiveFile, представлена ниже:
Пример запроса на выгрузку архива:
|
Запрос |
GET http://device-address:80/downloadarchivefiie?cameraid=1&frorndatetirne=2014-10-01T00:00:00&todatetime=2014-10-01T01:20:05 |
|
Ответ |
HTTP/1.1 200 OK |
|
Content-Type: application/octet-stream |
10.4. В качестве альтернативы к описанным требованиям допускается использование проприетарных протоколов различного уровня, атрибутов и определений, совместимых с компонентами подсистем и видеоядра ЕЦХД.
10.5. Управление функциями средства видеонаблюдения:
Со стороны ЛСВН должны быть реализованы функции приема нижеперечисленных команд по протоколу HTTP (GET), перевод команд в поддерживаемый средством видеонаблюдения протокол и транслирование команд в соответствующее средство видеонаблюдения. При получении нижеперечисленных команд ЛСВН должна отправлять подтверждение о получении команд. Для п. 10.4.1 и 10.4.2 должны соблюдаться условия увеличения значения координат при повороте направо и движении вниз.
10.5.1. Относительное движение:
- относительное движение - функция управления средством видеонаблюдения относительно текущей точки обзора. Изменение точки обзора СВН должно происходить таким образом, чтобы точка, указанная в присланных координатах, оказывалась в центре изображения средства видеонаблюдения;
- область видимости средства видеонаблюдения делится на сетку, где центральная точка имеет координаты (х:0, у:0), левая верхняя (х:-7, у:7), правая нижняя (х:7, у:-7).
Допускается "оптическая" погрешность, возникающая в результате расстояния до объекта видимости.
Должна быть компенсирована "погрешность", возникающая за счет проекции сферы на плоскость.
Формат запроса:
http://{0}:80/execute?cameralD={1}&ip={2}&login={3}&pass={4}&action= {5}&x={6}&y={7}&z={8}&modelName={9}:
- cameraID - обязательный атрибут, идентификатор средства видеонаблюдения;
- ip - необязательный атрибут, IP-адрес средства видеонаблюдения (80 порт);
- login - обязательный атрибут, учетная запись средства видеонаблюдения;
- pass - обязательный атрибут, пароль доступа к средства видеонаблюдения;
- action - обязательный атрибут, имя команды (degreesmove2);
- x - обязательный атрибут, поворот в плоскости PAN [-7..0..7];
- y - обязательный атрибут, поворот в плоскости TILT [-7..0..7];
- z - обязательный атрибут, увеличение/уменьшение зума [-1..0..1];
- modelName - обязательный атрибут, модель средства видеонаблюдения.
10.5.2. Установка сцены обзора по координатам.
Установка сцены обзора по координатам - функция установки сцены обзора средства видеонаблюдения по присланным координатам. При установке сцены обзора за точку отсчета должны браться зум и координаты, предустановленные на данном средстве видеонаблюдения (нулевые значения зума и координат по умолчанию).
Формат запроса:
http://{0}:80/execute?cameralD={1}&ip={2}&login={3}&pass={4}&action= {5}&x={6}&y={7}&z={8}&modelName={9}:
- cameraID - обязательный атрибут, идентификатор средства видеонаблюдения;
- ip - необязательный атрибут, IP-адрес средства видеонаблюдения;
- login - обязательный атрибут, учетная запись средства видеонаблюдения;
- pass - обязательный атрибут, пароль доступа к средству видеонаблюдения;
- action - обязательный атрибут, имя команды (setposition);
- x - обязательный атрибут, установка в плоскости PAN [-180..0.. 180];
- y - обязательный атрибут, установка в плоскости TILT [-180..0..180];
- z - обязательный атрибут, значение зума [0.. 100];
- modelName - обязательный атрибут, модель средства видеонаблюдения.
10.5.3. Получение телеметрии средства видеонаблюдения.
Получение телеметрии средства видеонаблюдения - функция, позволяющая получать данные о сцене видеонаблюдения (направление СВН по оси X, оси Y, значение зума).
Формат запроса:
http://{0}:80/execute?cameraID={1}&io={2}&login={3}&pass={4}&action= {5}&modetName={6}.
Получение положения средства видеонаблюдения в плоскостях PAN и TILT в градусах, а также текущие значение зума.
Ответ должен быть в формате JSON: ("y":56, "x":105, "z":0) в соответствии с требованиями к x, y, z, указанными в п. 10.5.2:
- cameraID - обязательный атрибут, идентификатор средства видеонаблюдения;
- ip - необязательный атрибут, IP-адрес средства видеонаблюдения;
- login - обязательный атрибут, учетная запись средства видеонаблюдения;
- pass - обязательный атрибут, пароль доступа к средству видеонаблюдения;
- action - обязательный атрибут, имя команды (getposition);
- modelName - обязательный атрибут, модель средства видеонаблюдения.
10.6. Возможно PTZ-управление посредством протокола ONVIF в случае поддержки ЛСВН ONVIF Profile S 1.0 в части PTZ-управления средствами видеонаблюдения. Примеры запросов представлены ниже.
10.6.1. Получение текущей телеметрии камеры.
Запрос через onvif-протокол:
POST /onvif/ptz_service HTTP/1.1
Content-Type: application/soap+xml
Content-Length: 996
charset: utf-8
Host: 10.53.42.56
Connection: close
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<Security s:mustUnderstand-"1" xmlns="http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<UsernameToken>
<Username>admin</Username>
<Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401- wss-username-token-profi/e- 1.0#PasswordDigest"> CknbdOHVhwlbelbwHzxRr2ezGc8=</Password>
<Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis- 200401-wss-soap-message-security- 1.0#Base64Binary">bUcvNakZWNacvnE4dfyGYQ==</Nonce>
<Created xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401- wss-wssecurity-utility-1,0.xsd">2018-01-23T11:59:28.159Z</Created>
</UsernameToken>
</Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<GetStatus xmlns="http://www.onvif.org/ver20/ptz/wsdl">
<ProfileToken>MediaProfile000</ProfileToken>
</GetStatus>
</s:Body>
</s:Envelope>HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Connection: close
Content-Length: 751.
Ответ:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<s:Envelope xmlns.s="http://www.w3.org/2003/05/soap-envelope
"xmlns:sc="http://www.w3.org/2003/05/soap-encoding"
xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl"
xmlns:tt="http://www.onvif.org/ver10/schema"><s:Header/>
<5:Body><tptz:GetStatnsResponse>
<tptz:PTZStatus>
<tt:Position>
<tt:PanTilt
space="http://www.onvif.org/ver10/tptz/PanTiltSpaces/PositionGeneric Space"
x="0.000000"y="-0.000000"/>
<tt:Zoom
space="http://www.onvif.org/ver10/tptz/ZoomSpaces/PositionGenericSpa ce"
x="0.033333"/>
</tt:Position>
<tt:MoveStatus>
<tt:PanTilt>IDLE</tt:PanTilt>
<tt:Zoom>IDLE</tt:Zoom>
</tt:MoveStatus>
< tt:UtcTime>2018-01-23T11:59:29Z</tt:UtcTime>
</tptz:PTZStatus>
</tptz:GetStatusResponse>
</s:Body>
</s:Envelope>.
10.6.2. Поворот по относительным координатам.
Запрос через onvif-протокол о получении возможности смещения:
POST/onvif/ptz_service HTTP/1.1
Content-Type: application/soap+xml
Content-Length: 941
charset: utf-8
Host: 10.53.42.56
Connection: close
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<Security s:mustUnderstand="1"xmlns-"http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<UsernameToken>
<Username>admin</Username>
<Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-username-token-profile-
1.0#PasswordDigest"> 1jCdlr25AXU1rjbD92f4/rtBQKg=</Password>
<Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-soap-message-security-
1,0#Base64Binary">5UjvJbXtZdhbeNWjahMO3w==</Nonce>
<Created xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd">2018-01-23T11:50:17.166Z</Created>
</Username Token>
</Security>
</s:Header>
<s:Body xmlns:xsi="http.//www.w3.org/2001/XMLSchema-instance"
xmlns.xsd="http://www.w3.org/2001/XMLSchema">
<GetNodes xmlns="http://www.onvif.org/ver20/ptz/wsdl"/>
</s:Body>
</s:Envelope>HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Connection: close
Content-Length: 2874.
Ответ:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:sc="http://www.w3.org/2003/05/soap-encoding"
xmlns:tptz-"http://www.onvif.org/ver20/ptz/wsdl"
xmlns:tt="http://www.onvif.org/ver10/schema"><s:Header/>
<s:Body>
<tptz:GetNodesResponse><tptz:PTZNode FixedHomePosition="false" token="000">
<tt:Name>PTZNode_Channel1</tt:Name>
<tt.SupportedPTZSpaces>
<tt:AbsolutePanTiltPositionSpace>
<tt:URI>http://www.onviforg/ver10/tptz/PanTiltSpaces/PositionGeneric Space</tt:URI>
<tt:XRange>
<tt:Min>-1.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:XRange>
<tt:YRange>
<tt:Min>-1.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:YRange>
</tt:AbsolutePanTiltPositionSpace>
< tt:AbsoluteZoomPositionSpace>
<tt:URI>http://www.ofwif.org/ver10/tptz/ZoomSpaces/PositionGenericSp ace</tt:URI>
<tt:XRange>
<tt:Min>0.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:XRange>
</tt:AbsoluteZoomPositionSpace>
<tt:RelativePanTiltTramlationSpace>
<tt:URl>http://www.onvif.org/verlO/tptz/Pan TiItSpaces/TranslationGenericSpace</tt:UR1>
<tt:XRange>
<tt:Min>-1.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:XRange>
<tt:YRange>
<tt:Min>-1.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:YRange>
</tt:RelativePanTiltTranslationSpace>
<tt:RelativeZoomTransIationSpace>
<tt:URI>http://www.onvif.org/ver10/tptz/ZoomSpaces/TranslationGeneri cSpace</tt:URL>
<tt:XRange>
<tt:Min>-1.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:XRange>
</tt:RelativeZoomTranslationSpace>
<tt:ContinuousPanTiltVelocitySpace>
<tt:URI>http://www.onvif.org/ver10/tptz/PanTiltSpaces/VelocityGeneri cSpace</tt:URI>
<tt:XRange>
<tt:Min>-1.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:XRange>
<tt:YRange>
<tt:Min>-1.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:YRange>
</tt:ContinuousPanTiltVelocitySpace>
<tt:ContinuousZoomVelocitySpace>
<tt:URI>http://www.onvif.org/ver10/tptz/ZoomSpaces/VelocityGenericSp ace</tt:URI>
<tt:XRange>
<tt:Min>-1.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:XRange>
</tt:ContinuousZoomVelocitySpace>
<tt:PanTiltSpeedSpace>
<tt:URI>http://www.onvif.org/ver10/tptz/PanTiltSpaces/GenericSpeedSp ace</tt:URI>
<tt:XRange>
<tt:Min>0.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:XRange>
</tt:PanTiltSpeedSpace>
<tt:ZoomSpeedSpace>
<tt:URI>http://www.onvif.org/ver10/tptz/ZoomSpaces/ZoomGenericSpeedS pace</tt:URI>
<tt:XRange>
<tt:Min>0.000000</tt:Min>
<tt:Max>1.000000</tt:Max>
</tt:XRange>
</tt:ZoomSpeedSpace>
</tt:SupportedPTZSpaces>
<tt:MaximumNumberOfPresets>80</tt:MaximumNumberOfPresets>
<tt:HomeSupported>true</tt:HomeSupported>
<tt:Extension>
<tt:SupportedPresetTour>
<tt:MaximumNumberOfPresetTours>8</tt:MaximumNumberOfPresetTours>
<tt:PTZPresetTourOperation>Start</tt:PTZPresetTourOperation>
<tt:PTZPresetTourOperation>Stop</tt:PTZPresetTourOperation>
<tt:PTZPresetTourOperation>Pause</tt:PTZPresetTourOperation>
</tt:SupportedPresetTour>
</tt:Exteasion>
</tptz:PTZNode>
</tptz: GetNodesResponse>
</s:Body>
</s:Envelope>.
Запрос на смещение:
POST/onvif/ptz_service HTTP/1.1
Content-Type: application/soap+xml
Content-Length: 996
charset: utf-8
Host: 10.53.42.56
Connection: close
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<Security s:mustUnderstand="1"xmlns="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<UsernameToken>
<Username>admin</Username>
<Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-username-token-profile-
1,0#PasswordDigest">A82JDpbtB8RattHNdt4IF8NwrZM=</Password>
<Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-soap-message-security-
1.0#Base64Binaiy">X9oW2eoL0Ygp/ocriVWmww==</Nonce>
<Created xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd">2018-01-23T11:50:17.199Z</Created>
</Username Token>
</Security>
</s:Header>
<s: Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<GetStatus xmlns="http://www.onvif.org/ver20/ptz/wsdl">
<ProfileToken>MediaProfile000</ProfdeToken>
</GetStatus>
</s:Body>
</s:Envelope>HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Connection: close
Content-Length: 752.
Ответ:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:sc="http://www.w3.org/2003/05/soap-encoding"
xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl"
xmlns:tt="http://www.onvif.org/ver10/schema"><s:Header/>
<s:Body>
<tptz:GetStatusResponse>
<tptz.PTZStatus><tt:Position><tt.PanTilt
space="http://www.onvif.org/ver10/tptz/PanTiltSpaces/PositionGeneric Space" x="-
0.468889" y="-0.026667"/>
<tt:Zoom
space="http://www.onvif.org/ver10/tptz/ZoomSpaces/PositionGenericSpa ce"
x="0.033333"/>
</tt:Position>
<tt:MoveStatus>
<tt:PanTilt>IDLE</tt:PanTilt>
<tt:Zoom>IDLE</tt:Zoom>
</tt:MoveStatus>
<tt:UtcTime>2018-01-23T11:50:18Z</tt:UtcTime>
</tptz:PTZStatus>
</tptz:GetStatusResponse>
</s:Body>
</s:Envelope>.
Запрос:
POST/onvif/ptz_service HTTP/1.1
Content-Type: application/soap+xml
Content-Length: 1288
charset: utf-8
Host: 10.53.42.56
Connection: close
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<Security s:mustUnderstand="1"xmlns="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<Username Token>
<Username>admin</Username>
<Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-username-token-profile-
1.0#PasswordDigest">HbpOv0+O+fSEKV/nyfJcQ9cRZ44=</Password>
<Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-soap-message-security-
1.0#Base64Binary">kLKNgVA/6dKrXbB52r6mow==</Nonce>
<Created xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd">2018-01-23T11:50:17.245Z</Created>
</UsernameToken>
</Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RelativeMove xmlns="http://www.onvif.org/ver20/ptz/wsdl">
<ProfileToken>MediaProfile000</ProfileToken>
<Translation>
<PanTilt x="0" y="0"
xmlns="http://www.onvif.org/ver10/schema"/>
<Zoom x="0"xmlns="http://www.onvif.org/ver10/schema"/>
</Translation><Speed><PanTilt x="0.8" y="0.8" xmlns="http://www.onvif.org/ver10/schema"/>
<Zoom x="0.8"xmlns="http://www.onvif.org/ver10/schema"/>
</Speed>
</RelativeMove>
</s:Body>
</s:Envelope>HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Connection: close
Content-Length: 332.
Ответ:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<s: Envelope xmlns.s="http://www.w3.org/2003/05/soap-envelope"
xmlns:sc="http://www.w3.org/2003/05/soap-encoding"
xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl"
xmlns:tt="http://www.onvif.org/ver10/schema"><s:Header/>
<s:Body>
<tptz:RelativeMoveResponse/>
</s:Body>
</s:EnveIope>.
10.6.3. Запрос на перевод по абсолютным координатам:
Запрос через протокол onvif:
POST/onvif/ptz_service HTTP/1.1
Content-Type: application/soap+xml
Content-Length: 1282
charset: utf-8
Host: 10.53.42.56
Connection: close
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<Secnrity s:mustUnderstand="1"xmlns="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<UsernameToken>
<Username>admm</Username>
<Password Type="http://docs/oasis-
open.org/wss/2004/01/oasis-200401-wss-username-token-profde-
1.0#PasswordDigest">W8kJZ3hDfPMhecfiq2Kr0//++AU=</Password>
<Nonce EncodingType="http://docs.oasis-
open.org/wss/2004/01/oas is-200401-wss-s oap-message-security
- 1.0#Base64Binary">QVyci8GaWOszPThWNyHPnA==</Nonce>
<Created xmlns="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">20 18-01-
23T11:55:49.156Z</Created>
</UsernameToken>
</Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<AbsoluteMove xmlns="http://www.onvif.org/ver20/ptz/wsdl">
<ProfileToken>MediaProfdeOOO</ProfileToken>
<Position>
<Pan Tilt x="0" y="0"
xmlns="http://www.onvif.org/ver10/schema"/>
<Zoom x="0"
xmlns="http://www.onvif.org/ver10/schema"/>
</Position>
<Speed>
<Pan Tilt x="0.8" y="0.8"
xmlns="http://www.onvif.org/ver10/schema"/>
<Zoom x="0.8"
xmlns="http://www.onviforg/ver10/schema"/>
</Speed>
</AbsoluteMove>
</s:Body>
</s:Envelope>HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Connection: close
Content-Length: 332.
Ответ:
<?xml version=" 1.0" encodings="utf-8" standalone="yes"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:sc="http://www.w3.org/2003/05/soap-encoding"
xmlns: tptz="http://www.onvif.org/ver20/ptz/wsdl"
xmlns:tt="http://www.onvif.org/ver10/schema"><s:Header/>
<s:Body>
<tptz: AbsoluteMoveResponse/>
</s:Body>
</s:Envelope>.
Приложение 4
к Регламенту передачи информации
об объектах видеонаблюдения
в государственную информационную
систему "Единый центр хранения
и обработки данных" из локальных
систем видеонаблюдения
Типовая форма Соглашения
о взаимодействии при предоставлении информации в государственную
информационную систему "Единый центр хранения и обработки данных"
г. Москва "__" __________ 20__ г.
Департамент информационных технологий города Москвы в лице
_______________________, действующего на основании _____________________,
именуемый в дальнейшем "Департамент", с одной стороны, и ________________
__________________________________________________________________ в лице
(наименование органа государственной власти, организации)
________________________________________________________________________,
(должность) (фамилия, имя, отчество)
действующего на основании _______________________, именуемый в дальнейшем
"Поставщик информации", с другой стороны, при совместном упоминании
именуемые "Стороны", в целях обеспечения взаимодействия при
предоставлении информации об объектах видеонаблюдения, содержащейся в
локальных системах видеонаблюдения Поставщика информации (далее -
предоставление информации), подключенных к государственной информационной
системе "Единый центр хранения и обработки данных" (далее - ЕЦХД),
технической поддержке подключения локальных систем видеонаблюдения к
ЕЦХД, предоставления доступа к информации, хранимой в ЕЦХД заключили
настоящее Соглашение.
1. В целях исполнения настоящего Соглашения используются следующие
термины и определения:
ЛСВН - локальная система видеонаблюдения Поставщика информации.
Оператор ЕЦХД - Департамент информационных технологий города Москвы
(далее - Департамент), Государственное казенное учреждение города Москвы
"Московское городское агентство по телекоммуникациям" (в части
эксплуатации и иного технического сопровождения ЕЦХД в соответствии с
распоряжением Департамента информационных технологий города Москвы от
04.09.2012 N 64-16-749/12).
СТП - служба технической поддержки Оператора ЕЦХД.
Средство видеонаблюдения - камера видеонаблюдения, иное
программно-техническое устройство, предназначенное для формирования
информации об объекте видеонаблюдения, в том числе видеоизображения
объекта видеонаблюдения.
Первый тип интеграции - тип интеграции, предусматривающий
обеспечение постоянной передачи видеоизображений со средств
видеонаблюдения в ЕЦХД в режиме реального времени, в формате, совместимом
с управляющими системами ЕЦХД, и с качеством в соответствии с
требованиями Регламента. * Возможность доступа к трансляции архива,
хранение архива, а также выгрузка архива видеоизображений обеспечивается
программно-техническими средствами ЕЦХД.
Второй тип интеграции - тип интеграции, предусматривающий
обеспечение передачи видеоизображений со средств видеонаблюдения в ЕЦХД
по запросу управляющих систем ЕЦХД, а также хранение архивов
видеоизображений на оборудовании Поставщика информации в совместимом с
управляющими системами ЕЦХД формате, трансляция архивов видеоизображений
в ЕЦХД и выгрузка архивов видеоизображений с оборудования Поставщика
информации стандартными средствами управляющих систем ЕЦХД в соответствии
с требованиями Регламента. *
Третий тип интеграции - тип интеграции, предусматривающий
обеспечение постоянной передачи видеоизображений со средств
видеонаблюдения в ЕЦХД в режиме реального времени, в формате, совместимом
с управляющими системами ЕЦХД, и с качеством в соответствии с
требованиями Регламента. * Удаленный доступ к трансляции архива, хранение
и выгрузка архива видеоизображений средствами ЕЦХД не поддерживаются.
Регламент - Регламент передачи информации об объектах
видеонаблюдения в государственную информационную систему "Единый центр
хранения и обработки данных" из локальных систем видеонаблюдения,
утвержденный распоряжением Департамента информационных технологий города
Москвы от 31.07.2015 N 64-16-241/15.
РГВУ - Рабочая группа верхнего уровня, постоянно действующий
коллегиальный орган, осуществляющий свою деятельность в соответствии с
пунктом 13 Положения о государственной информационной системе "Единый
центр хранения и обработки данных", утвержденного постановлением
Правительства Москвы от 07.02.2014 N 24-ПП "Об утверждении положения о
государственной информационной системе "Единый центр хранения и обработки
данных", на основании совместного решения Департамента и Департамента
региональной безопасности и противодействия коррупции города Москвы о
создании такой Рабочей группы верхнего уровня, Регламента, а также иных
правовых актов Департамента. Состав Рабочей группы верхнего уровня может
включать в себя служащих отраслевых органов исполнительной власти города
Москвы, федеральных органов исполнительной власти и Департамента. Состав
Рабочей группы верхнего уровня утверждается совместным решением
Департамента и Департамента региональной безопасности и противодействия
коррупции города Москвы о создании такой Рабочей группы верхнего уровня.
ГАРАНТ:
По-видимому, в тексте предыдущего абзаца допущена опечатка. Дату названного постановления следует читать как "от 07.02.2012"
------------------------------
*Наличие данного абзаца в настоящем Соглашении может варьироваться в зависимости от принадлежности Поставщика информации к органам государственной власти либо к иным организациям.
------------------------------
2. Предмет Соглашения
2.1. Предметом настоящего Соглашения является порядок взаимодействия
Сторон при передаче в ЕЦХД информации об объектах видеонаблюдения,
содержащейся в ЛСВН, а также порядок взаимодействия СТП и ответственных
представителей Поставщика информации (в соответствии с приложением 1 к
настоящему Соглашению) в рамках технической поддержки подключения ЛСВН к
ЕЦХД.
2.2. Предоставление информации в ЕЦХД осуществляется Поставщиком
информации в соответствии Регламентом и иными нормативными правовыми
актами Российской Федерации и города Москвы.
2.3. В рамках настоящего Соглашения взаимодействие Сторон
осуществляется на безвозмездной основе с соблюдением требований
нормативных правовых актов Российской Федерации и города Москвы.
2.4. Перечень средств видеонаблюдения ЛСВН, информация с которых
передается в ЕЦХД, указывается в приложении к Сертификату ЛСВН.
3. Обязанности Сторон
3.1. Стороны обязуются самостоятельно обеспечивать эксплуатацию
технических и программных средств, каналов связи, необходимых каждой из
Сторон для организации и осуществления взаимодействия по Соглашению.
3.2. Департамент обязуется:
3.2.1. Консультировать Поставщика информации по вопросам подключения
ЛСВН к ЕЦХД.
3.2.2. Обеспечить прием переда
|
<< Назад |
||
|
Содержание Распоряжение Департамента информационных технологий г. Москвы от 13 ноября 2020 г. N 64-16-613/20 "О внесении изменений... |