Размещено на http://www.allbest.ru/

Оглавление

• Введение
• 1.Обзор предметной области
• 1.1 Сравнительный анализ ONVIF и PSIA
• 2.Актуальность темы
• 3.Анализ существующих технических решений
• 4.Средства и методы разработки
• 5.Постановка задачи
• 6.Процесс разработки библиотеки
• 6.1 Реализация SOAP
• 6.2 Реализация ONVIF сервисов
• 6.3 Реализация WS-Security
• 6.4 Реализация WS-Discovery
• 6.5 Разработка высокоуровневых функций
• 6.6 Описание работы с библиотекой
• 7.Процесс разработки веб-сервиса
• 7.1 Веб-интерфейс
• Заключение
• Список использованных источников


Введение

библиотека сервис security discovery

Развитие сетевых технологий привело к тому, что сегодня доступ в Интернет имеют не только обычные компьютеры, но и многие устройства. Такое развитие не обошло стороной и сферу видеотехнологий. Сегодня существуют специальные камеры, называемые IP-камерами, которые не только позволяют передавать видеопоток по сети, но также имеют функционал для управления ими по сети.

С началом бурного развития видеотехнологий и широкого распространения систем видеонаблюдения началась активная разработка IP-видеооборудования. Создание новых технологий приводили к появлению новых функций, например, способности камеры реагировать на события или автоматически следовать за движением объекта. В результате рост популярности таких устройств привел к появлению большого числа производителей IP-камер. При этом продукция различных производителей различается как функциональностью, так и программным обеспечением, предложенным производителями для настройки и использования всего многообразия функций данного продукта. В результате на рынке появилось большое количество оборудования от разных разработчиков, у которых не были способны взаимодействовать друг с другом. Данное оборудование сильно отличается друг от друга, начиная предоставляемыми функциями, заканчивая конфигурацией сети, схемами кодирования/сжатия видео, поддерживаемыми сетевыми протоколами и т.д. Программный интерфейс, предлагаемый производителями для настройки и использования функциональных возможностей устройств, также различается. Более того, различия проявлялись и в оборудовании, разработанном внутри одной компании. Например, когда производитель камеры выпускает новую линейку моделей, он вынужден разработать для нее и новую спецификацию, а также набор протоколов. Таким образом, данный факт привел к появлению серьезной проблемы совместимости устройств.

В настоящее время в отрасли видеотехнологий совместимость аппаратного обеспечения, в особенности устройств, произведенных разными компаниями, является актуальной проблемой. И, если раньше, для работы с таким оборудованием приходилось, например, писать отдельное ПО для каждого устройства, то сегодня существуют определенные стандарты, которые позволяют работать с такими устройствами. Одним из таких стандартов является спецификация ONVIF, которая, в первую очередь, была нацелена на решение проблемы несовместимости оборудования. ONVIF - Open Network Video Interface Forum - это не просто стандарт, это глобальная международная организация, занимающаяся разработкой стандартизированных протоколов для взаимодействия различного оборудования и программных средств. Одним из направлений работы организации является стандартизация методов взаимодействия между собой IP-устройств в отрасли видеонаблюдения или обеспечение совместимости устройств систем безопасности. [1]



1. Обзор предметной области

Долгое время проблема совместимости IP оборудования оставалось серьезной проблемой. Поэтому для решения данной проблемы в 2008 году компании Axis Communications, Bosch Security Systems и Sony Corporation создали международный форум, целью которого стало создание единого стандарта для взаимодействия оборудования различных производителей.[2] В этом же году с разницей в несколько месяцев создается альянс PSIA [3], который своей целью также ставит стандартизацию систем видеонаблюдения. Сегодня PSIA является единственным конкурентом ONVIF.

ONVIF активно развивался с момента его создания. В декабре 2009 года в членство ONVIF входило 103 организации. В декабре 2010 года в форум входило более 240 членов и более 440 соответствующих продуктов было представлено на рынке. К январю 2015 года число продуктов совместимых с ONVIF выросло до 3700, а количество компаний, состоящих в форуме возросло до 500 членов.

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

Текущая версия спецификации 17.12 была опубликована в декабре 2017 года. Она состоит из множества частей: базовая спецификация, спецификация форматов данных, спецификация сервисов, спецификация тестирования, ONVIF Conformance Process Specification, ONVIF Web Service Definition Language (WSDL), and Extended Markup Language (XML) Schema Specifications. [4]



1.1 Сравнительный анализ ONVIF и PSIA

В основе стандарта ONVIF лежат целое множество стандартов web-сервисов: SOAP, WS-Discovery, WS-Security, XML, WSDL. XML используется для представления данных; SOAP - для передачи сообщений; WSDL используется для описания сервисов; WS-Discovery - для динамического обнаружения устройств; WS-Security - для обеспечения безопасности. Таким образом, поскольку ONVIF опирается на целое семейство спецификаций, он является более сложным в реализации. [5]

Стандарт PSIA в отличие от ONVIF для коммуникации между клиентом и устройством использует более простую архитектуру REST. [6] REST более прост в освоении, требует меньше аппаратных ресурсов и гораздо меньший объем канала передачи данных, поэтому является с точки зрения программирования и быстродействия более привлекательным.

С другой стороны, с точки зрения совместимости при обнаружении устройств выигрывает стандарт ONVIF, так как он опирается на спецификацию WS_Discovery [5], в то время как PSIA предлагает более широкий спектр протоколов поиска устройств в сети (Zeroconf, UPnP и Bonjour) [6], а это значит, что устройство, работающее по протоколу UPnP будет иметь определенные проблемы при взаимодействии с устройством работающим по протоколу Bonjour.



2. Актуальность темы

В XXI веке с развитием технологий с каждым годом растет потребность в камерах, управляемых по протоколу IP. Задача управления камерами достаточно сложна, поэтому был создан стандарт ONVIF, который определяет мельчайшие детали управления камерой.

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

Говоря о важности работы важно заметить, что стандарт ONVIF был создан относительно недавно (в 2008 году) и популярность он начал завоевывать только в настоящее время. Это привело к тому, что разработчики программного обеспечения для систем видеонаблюдения сегодня сталкиваются с проблемой недостатка необходимых инструментов для разработки своих приложений. Более того, существующие утилиты не реализуют стандарт ONVIF полностью, а также не обладают высокоуровневой функциональностью. В рамках проекта была поставлена задача разработать библиотеку на языке программирования Go, которая будет полностью реализовывать стандарт ONVIF, а также обладать некоторыми высокоуровневыми функциями, упрощающими работу с ONVIF устройствами.



3. Анализ существующих технических решений

Аналогичные нашему проекту технические решения существуют, но являются недостаточно хорошо реализованными и плохо документированными. По этой причине важность проекта многократно возрастает. Одним из существующих решений является библиотека python-onvif-zeep, которая реализует практически все сервисы, описанные в стандарте. Минусом данной реализации является то, что она практически не документирована и в ней не разобраться, без изучения исходного кода библиотеки, что приведет к трате большого количества времени. Также существует решение с использованием языка Java, но данная библиотека давно не поддерживается и в ней реализована не вся функциональность, описанная в стандарте.

Существует также решение аналогичное нашему веб-сервису. Данный программный продукт называется Onvif Device Manager, разработанный компанией Synesis. Данное приложение позволяет управлять основными настройками PTZ-камер, но обладает рядом недостатков. Основными недостатками программы являются ее медленная работа, долгое подключение к удаленным камерам, отсутствие мнопользовательской аутентификации, невозможность управления несколькими камерами через один интерфейс, невозможность изменения некоторых настроек камеры, частое подвисание видеотрансляции с выдачей сообщения “No signal” в то время, как в плеере трансляция не прерывается, также минусом программы является ее сложный и непродуманный интерфейс.



4. Средства и методы разработки

Вначале данной работы необходимо было выбрать инструменты, при помощи которых быстро и эффективно можно бы было реализовать библиотеку по управлению камерами, а также веб-сервис, предназначение которого показать некоторые возможности библиотеки. Данными инструментами стали язык программирования Go, программная платформа Node.js и библиотека ReactJS.

Язык программирования Go - разработка компании Google. Go -- это компилируемый язык общего назначения. Он был выбран для написания библиотеки по причине своей хорошей сбалансированности между быстродействием и высокоуровневостью. Это означает, что несмотря на легкость написания кода, быстродействие Go почти достигает уровня таких языков программирования, как С, С++. Также необходимо отметить, что Go разрабатывался как язык с улучшенной облегченной поддержкой многопоточности, что необходимо при реализации данной библиотеки при создании REST API.

Платформа Node.js используется для реализации Backend-а веб-сервиса. Данная платформа легковесная, хорошо документированная, масштабируемая, поэтому она была выбрана для реализации основных задач на стороне сервера.

В качестве FrontEnd-а используется библиотека ReactJS. Она кроссбраузерная и обладает встроенной самой широкой функциональностью для быстрой и эффективной реализации интерфейса веб-сервиса.



5. Постановка задачи

Необходимо разработать библиотеку, реализующую стандарт ONVIF. Для демонстрации возможности библиотеки разработан web-сервис, позволяющий управлять PTZ-камерами. Данный web-сервис опирается на разработанную библиотеку для общения с PTZ-камерами.

Поставленные задачи были разделены следующим образом.

Паланджян Жоржик Араратович решает следующие задачи:

1. Реализация следующих сервисов ONVIF:

? Device Management;

? Media;

? Imaging.

2. Реализация REST API для взаимодействия с библиотекой независимо от выбранного языка программирования;

3. Реализация стандарта динамического обнаружения устройств «Web Services Dynamic Discovery»: реализация отправки multicast запросов и получение ответов.

Яковлев Дмитрий Валерьевич решает следующие задачи:

1. Реализация следующих сервисов ONVIF:

? PTZ;

? Recording;

? Analytics.

2. Разработка веб-сервиса, демонстрирующего функциональные возможности библиотеки.

3. Реализация стандарта динамического обнаружения устройств «Web Services Dynamic Discovery»: генерация запросов, в соответствии с [11].

Следующие задачи выполнялись совместно:

1. Проектирование архитектуры библиотеки.

2. Тестирование библиотеки

3. Реализация высокоуровневых функций, упрощающих выполнение рутинных процедур, которые не определены в стандарте ONVIF.

4. Реализация высокоуровневых функций для упрощения процесса видеосъемки.



6. Процесс разработки библиотеки

6.1. Реализация SOAP

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

Для реализации данного протокола был разработан пакет gosoap (https://github.com/yakovlevdmv/gosoap). Рассмотрим структуру и принцип работы пакета. Данный пакет работает на основе стороннего пакета etree (https://github.com/beevik/etree). Пакет etree позволяет парсить и генерировать XML документы. Его дизайн был вдохновлен модулем Python ElementTree.

6.2. Реализация ONVIF сервисов

Из документа ONVIF Core Specification [5] следует, что основной принцип внедрения спецификации ONVIF, состоит в следующем: взаимодействие выполняется между поставщиком услуг, который является устройством ONVIF, и клиентом, которым в нашем случае является разрабатываемая библиотека. Вся функциональность ONVIF устройства, а также используемые при взаимодействии типы данных определены в WSDL документе. Поэтому для интеграции этих функций используется WSDL компилятор, который анализирует информацию, закодированную в WSDL документе и генерирует необходимый код, который затем интегрируется клиентом (библиотекой). Данный принцип наглядно представлен на рис. 1.

В связи с тем, что для языка Go не существует такого компилятора, нами был разработан свой компилятор, однако он разрабатывался под WSDL документы специфичные для ONVIF, поэтому не гарантируется его работа с другими веб-сервисами. С использованием данного компилятора были сгенерированы Go-структуры, описывающие типы данных, используемые в реализуемых ONVIF сервисах: PTZ, Recording, Analytics. Ниже приведен пример такой структуры для функции CreateUsers:

Типы данных каждого сервиса выделены в отдельный пакет, так как во многих сервисах есть совпадающие типы.

Рис 1. Основной принцип разработки клиента ONVIF сервиса

Для представления ONVIF устройства в библиотеке реализована структура device, листинг которой приведен ниже:



Листинг 3. Структура device.

Она содержит в себе адрес камеры, логин, пароль доступа к ней, список точек доступа к ONVIF сервисам и информацию об устройстве. Описание работы с библиотекой, в частности с структурой device приведены в следующем разделе.

6.3. Реализация WS-Security

Авторизация между клиентом и устройством осуществляется посредством спецификации WS-Security [8], а именно, WS-UsernameToken. Когда устройство требует аутентификации через WS-UsernameToken, клиент должен установить информацию о пользователе с соответствующими правами в заголовке WS-UsernameToken [9], [10]. На листинге 4 представлена XML структура элемента UsernameToken.

Элемент WS-UsernameToken требует следующую информацию [10]:

? Username - имя сертифицированного пользователя

? Nonce - случайная последовательность, генерируемая клиентом

? Created - время создания и отправки запроса

? Password - пароль соответствующий текущему пользователю, имя которого передано в поле Username. Согласно спецификации ONVIF пароль не должен отправляться как обычный текст. Для его передачи необходимо сгенерировать PasswordDigest. Алгоритм генерации определен в спецификации WS-UsernameToken:

Digest = B64ENCODE( SHA1( B64DECODE( Nonce ) + Date + Password ) )

Листинг 4. XML структура элемента UsernameToken

Рассмотрим программную реализацию протокола WS-UsernameToken в разработанной библиотеке. Ниже приведен листинг используемых структур, описывающих элемент UsernameToken. (см. листинг 5)

Листинг 5. Программная реализация UsernameToken.



Для генерации объекта UsernameToken используется функция конструктор NewSecurity(username, passwd string). (см. листинг 6)

Листинг 6. Функция NewSecurity(username, passwd string)

Как видно из листинга 6 функция возвращает новый объект типа security (см. листинг 5). Для генерации PaswordDigest используется функция представленная в листинге 7.

Листинг 7. Генерация PasswordDigest



6.4. Реализация WS-Discovery

Стандарт ONVIF требует, чтобы ONVIF устройства реализовывали спецификацию Web Services Dynamic Discovery [11]. Данный стандарт обеспечивает автоматическое обнаружение устройств в сети. Для реализации клиентской стороны стандарта WS-Discovery был разработан пакет WS-Discovery(https://github.com/yakovlevdmv/WS-Discovery), осуществляющий поиск всех ONVIF устройств типа NetworkVideoTransmitter [12], в данный момент подключенных к сети.

Стандарт WS-Discovery использует протокол SOAP для обмена сообщениями. Принцип работы стандарта представлен на рис. 2.

Рис 2. Принцип работы WS-Discovery

Сообщения об обнаружении устройств отправляются в multicast режиме, а ответ приходит от устройства unicast-режиме. Основной принцип обнаружения устройств, следующий [11]:

1. Веб-сервисы при подключении к сети отправляют, так называемое Hello запрос в multicast-режиме. Клиент слушает данные Hello сообщения для обнаружения устройств, подключаемых к сети.

2. Клиент отправляет Probe сообщение в multicast-режиме для обнаружения устройств по типу сервиса. Если устройство соответствует типу, запрашиваемому в Probe сообщении, то оно отвечает сообщением ProbeMatch в unicast-режиме.

3. Клиент отправляет Resolve сообщение в multicast-режиме для обнаружения устройств по имени сервиса. Если устройство соответствует имени, запрашиваемому в Probe сообщении, то оно отвечает сообщением ResolveMatch в unicast-режиме.

4. Когда устройство отключается от сети, то оно отправляет Bye сообщение в multicast-режиме, таким образом сообщая о том, что оно больше не доступно в сети.

Все multicast сообщения должны быть отправлены с использованием следующих установок [11]:

? DISCOVERY_PORT: port 3702

? IPv4 multicast address: 239.255.255.250

? IPv6 multicast address: FF02::C (link-local scope)

Для реализации WS-Discovery был разработан пакет https://github.com/yakovlevdmv/WS-Discovery. Данный пакет реализует лишь функциональность отправки Probe сообщения для обнаружения устройств по типу сервиса, в случае разрабатываемой библиотеки - NetworkVideoTransmitter.

6.5. Разработка высокоуровневых функций

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

В процессе работы на базе разработанной библиотеки были реализованы следующие функции:

? Плавный разгон и плавное торможение камеры.

? Панорамная съемка - съемка с большим углом обзора, превышающим возможности объектива IP-камеры.

Рассмотрим реализацию каждой вышеописанной функции:

1. Плавный разгон.

С физической точки зрения данный процесс описывается следующей формулой:

, (1)

где x1 - конечная координата, x0 - начальная координата, a - ускорение, t - время движения.

Как видно из формулы 1, теоретически возможно реализовать плавный разгон, задав начальную точку, конечную точку, скорость и время панорамирования. Однако, как оказалось на практике, большинство камер, с которыми проводилось тестирование не поддерживают функцию, возвращающую текущее положение камеры, более того, координаты каждой камеры нормированы относительно отрезка [-1;1]. Так, невозможно осуществить движение из точки А в точку B, поэтому было решено реализовать разгон следующим образом:

? На вход подается время в течение которого необходимо осуществлять разгон, а также вертикальная и горизонтальная составляющие вектора скорости движения камеры (обычно нормированы относительно отрезка [-1;1]).

? Рассчитывается дельта наращивания скорости движения камеры по формуле:

(2)

? В цикле, каждые 500 миллисекунд происходит увеличение скорости на dv и отправка запроса на камеру об осуществлении движения.

Таким образом, данные о скорости движения камеры обновляются каждые 500 миллисекунд, что было сделано для увеличения плавности разгона, так как параметр времени разгона принимается в секундах. Запрос об обновлении скорости к камере отправляется отдельным потоком, что позволяет сократить временные издержки на выполнение данного запроса.

В листинге 8 приведена реализация данной функции.

Листинг 8. Функция плавного разгона accelerate_up().



2. Плавное торможение.

Данная функция реализована по тому же принципу, что и функция разгона. Отличие лишь в том, что каждые 500 миллисекунд происходит уменьшение скорости движения камеры.

В листинге 9 приведена реализация данной функции.

Листинг 9. Функция плавного торможения accelerate_down().

3. Панорамная съемка.

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

Аргументами функции панорамирования являются следующие переменные: время в течение которого необходимо осуществлять съемку, а также вертикальная и горизонтальная составляющие вектора скорости движения камеры (обычно нормированы относительно отрезка [-1;1]). Также аргументом является доля времени, затрачиваемая на разгон/торможение камеры.

В листинге 10 приведена реализация данной функции.

Листинг 10. Функция панорамной съемки panoramicMove().

6.6. Описание работы с библиотекой

Библиотека Goonvif создана для упрощения взаимодействия с ONVIF устройствами. На данный момент в библиотеке реализована поддержка NVT(Network Video Transmitter) устройств, а именно следующих ONVIF сервисов:

? Core или DeviceManagement

? Media

? Imaging

? PTZ

? Analytics

? Recording

Для установки библиотеки необходимо воспользоваться утилитой go get:

go get github.com/yakovlevdmv/goonvif

Начало работы с библиотекой. Чтобы начать работать с камерой, необходимо создать объект типа device. Для этого необходимо воспользоваться функцией func NewDevice(xaddr string) (*device, error), которая принимает IP адрес либо DNS-имя ONVIF устройства и возвращает 2 параметра: указатель на структуру device и структур типа error, содержащую информацию об ошибке. Если при инициализации объекта структуры device возникла ошибка, то информация о ней будет содержаться во втором параметре - структуре типа error. Поэтому после создания объекта необходимо сразу проверить наличие ошибок. Если камера недоступна, указан неверный адрес для ONVIF сервиса камеры (возможно находится по другому порту) или же камера вообще не поддерживает ONVIF, то функция вернет error с информацией об ошибке, а в качестве указателя на объект устройства вернет nil.

Пример подключения к камере. Пусть камера в сети находится по адресу 127.0.0.1, а ее ONVIF сервисы расположены на порте 1234. Тогда,

dev, err := goonvif.NewDevice("127.0.0.1:1234")

сработает успешно, а

dev, err := goonvif.NewDevice("127.0.0.1:80")

вернет нулевой объект камеры и ошибку: «camera is not available at 127.0.0.1:80 or it does not support ONVIF services».

Модернизируем код, добавив обработку ошибки, и получим:

Листинг 11. Пример создания объекта device

Также можно воспользоваться функцией GetAvailableDevicesAtSpecificEthernetInterface для обнаружения устройств в сети по протоколу WS-Discovery:

devices := goonvif.GetAvailableDevicesAtSpecificEthernetInterface("Ethernet 2")

Поддерживаемые ONVIF сервисы. Теперь, когда камера доступна, можно приступать к работе с ней. Однако стандарт ONVIF имеет множество сервисов, а также точку доступа (endpoint) которая не определена стандартом (кроме DeviceManagment: http://onvif_host/onvif/device_service). Поэтому дальше встает вопрос о поддерживаемых камерой сервисах и определении их endpoint'ов. Для получения поддерживаемых камерой сервисов необходимо вызвать метод GetCapabilities сервиса DeviceManagement. Однако эта библиотека автоматизирует данный процесс, поэтому при создании объекта device при помощи func NewDevice(xaddr string) (*device, error) библиотека одновременно обрабатывает поддерживаемые камерой сервисы. Таким образом есть два способа получения поддерживаемых устройством сервисов:

? Вызвать метод GetCapabilities сервиса DeviceManagement (как это сделать будет рассмотрено дальше) и обработать ответ. (см. рис. 3)

Рис. 3. Фрагмент ответа от камеры

? Довериться библиотеке и вызвать функцию func (dev *device)GetServices() map[string]string, которая вернет объект типа map[string]string, ключом которой является название сервиса, а значением - точка доступа (HTTP адрес) данного сервиса. (см. рис. 4)

Рис. 4. Результат вызова функции (dev *device)GetServices()

Работа с камерой. Для работы с различными сервисами камерами необходимо отправить корректный SOAP запрос, в теле которого находится вызываемый метод и принимаемые им функции. Goonvif берет на себя работу по созданию корректного SOAP запроса и его отправке. В Goonvif определены структуры, для каждой функции каждого (поддерживаемого данной библиотекой) сервиса ONVIF:

? DeviceManagement Service

? Media Service

? Imaging Service

? PTZ Service

? Analytics Service

Список всех сервисов стандарта (и документация к ним) находятся по адресу: https://www.onvif.org/profiles/specifications/.

Рассмотрим, как организована отправка запросов в Goonvif на нескольких примерах.

1. Метод GetCapabilities сервиса DeviceManagement

Все необходимые типы данных определены в пакете Device. Содержимое [13] представлено на рисунке 5.

Рис 5. Метод GetCapabilities сервиса DeviceManagement

Из рисунка 1 следует, что функция GetCapabilities принимает в качестве аргумента перечисление: enum { 'All', 'Analytics', 'Device', 'Events', 'Imaging', 'Media', 'PTZ'}. Чтобы вызвать данный метод создадим объект Device.GetCapabilities:

capabilities := Device.GetCapabilities{Category:"All"}

Для вызова данной функции воспользуемся методом func (dev device) CallMethod(method interface{}) (string, error), а для чтения возвращаемого значения - функцией func readResponse(resp *http.Response) string, принимающей на вход структуру http.Resp и возвращающий ответ полученный от ONVIF устройства в виде объекта string. Пример представлен в листинге 9.

Листинг 12. Вызов метода GetCapabilities.

2. Создание пользователя методом CreateUsers сервиса DeviceManagement

Все необходимые типы данных определены в пакете Device. На рисунке 6 можно увидеть структуру запроса:

Рис. 6. Метод CreateUsers сервиса DeviceManagement

Для вызова данной функции, как и в предыдущем примере воспользуемся функцией func (dev device) CallMethod(method interface{}) (string, error). Создадим объект Device.CreateUsers:

Листинг 10. Вызов метода CreateUsers.

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

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

3. Метод ContinuousMove сервиса PTZ

Все необходимые типы данных определены в пакете PTZ. В файле [14] можно увидеть структуру запросов PTZ сервиса. На рисунке 7 представлен запрос ContinuousMove.

Рис. 13. Метод ContinuousMove сервиса PTZ

Так как данная команда определяется сервисом PTZ, необходимый тип находится в пакете PTZ. На рисунке 7 можно заметить, что:

ProfileToken [ReferenceToken]- A reference to the MediaProfile.

Таким образом, для того, чтобы начать работать с PTZ сервисом для начала необходимо получить ProfileToken сервиса Media. Как это сделать можно увидеть в примере 4. Сейчас же предположим, что нам известен нужный токен. Пусть ProfileToken = "Profile_1".

Создадим объект PTZ.ContinuousMove:



Листинг 14. Создание объекта ContinuousMove

Заметим, что объекты Velocity, PanTilt и Zoom определены в пакете onvif. Такое применение свойственно для большинства встроенных в структуру типов.

Для вызова данной функции воспользуемся методом func (dev device) CallMethod(method interface{}) (string, error):

Листинг 15. Вызов метода ContinuousMove

4. Получение списков Media профилей

Все необходимые типы данных определены в пакете Media. В файле [15] можно увидеть структуру запроса (рис.8)

Рисунок 8. Метод GetProfiles сервиса Media



Вот пример создания и вызова запроса GetProfiles:

Листинг 16. Создание объекта GetProfiles.

Заметим, что многие запросы требуют авторизованного доступа и для того, чтобы добавить авторизацию к конкретной камере, необходимо воспользоваться функцией func (dev *device) Authenticate(username, password string). После применения данной функции все отправляемые камерой запросы будут авторизованными. (см. листинг 14)

Листинг 17. Аутентификация..

Получить доступ к разработанной библиотеке можно по следующей ссылке https://github.com/yakovlevdmv/goonvif



7. Процесс разработки веб-сервиса

Процесс разработки веб-сервиса состоит из двух важных частей: разработка backend-а и разработка frontend-а.

Для разработки backend-а была выбрана платформа node.js [16], которая хорошо документирована и масштабируема. Это означает, что при необходимости добавления дополнительной функциональности в веб-сервис можно легко и без сложностей расширить функциональность веб-сервиса, при этом не влияя на уже реализованную функциональность. В node.js предусмотрена возможность быстрого создания необходимой структуры проекта, что, несомненно, приближает программиста к непосредственному программированию, написанию кода. Инструментом, предоставляющим такую возможность является express-generator. Необходимо выполнить следующую команду, чтобы установить эту программу:

Для генерации структуры проекта необходимо выполнить в командной строке следующую команду:

Надо сказать, что backend-app - название приложения и может быть любым в зависимости от предпочтений. Для того, чтобы в новосозданную структуру автоматически установилась зависимости, необходимые для начала программирования, нужно использовать команду npm install. В результате всех вышеописанных действий будет создана структура, начальный каркас backend-а, который можно изменять под свои нужды и дополнять необходимыми модулями, которые будут заточены под конкретное приложение. При создании веб-сервиса в данном конкретном случае получилась следующая структура файловая структура:

Рисунок 9. Структура проекта.

На рисунке 9 в корне проекта можно увидеть файл app.js. Данный файл является главным. В данном файле воедино собираются все части программы (index.js, users.js) для того, чтобы при запуске работать как единое целое. В файлах маршрутизации index.js, users.js находится код, который отвечает за ответ, приходящий на сервер по конкретному url. Также надо отметить файл www, находящийся в директории bin. Данный файл является «точкой входа» в приложение. Именно его надо запустить, чтобы начал работать сервер, который будет принимать запросы.

Для разработки frontend-а была выбрана библиотека ReactJS [17]. Преимуществами ReactJS являются быстродействие, частичная независимость исполнения сценариев от браузеров, возможность работы с новейшими стандартами без поддержки этих новейших стандартов всеми браузерами, хороший уровень абстракции, позволяющий не вдаваться в подробности реализации самой библиотеки, а также большое количество готовых и проверенных решений, которые можно интегрировать при помощи одной команды. Большинство данных преимуществ достигается счет того, что ReactJS на самом деле работает как в frontend-е, так и в backend-е. В backend-е происходит трансляция [18] нового стандарта JavaScript кода, который не поддерживается некоторыми браузерами либо поддерживается не полностью, в предыдущий стандарт, который умеют обрабатывать большинство браузеров. Также на стороне сервера работает сборщик ресурсов и библиотек, например webpack [19], который управляет, соединяет, а также компилирует множество ресурсов и библиотек и создает конечную страничку приложения, которую браузер покажет пользователю.

7.1 Веб-интерфейс

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

Веб-интерфейс представляет из себя многоступенчатую концепцию взаимодействия пользователя с функциональными возможностями библиотеки goonvif. Многоступенчатость концепция представляет из себя сервис, который обладает как frontend-ом, так backend-ом. Данный сервис предоставляет высокоуровневый интерфейс для управления ip-устройствами.

Общая схема реализации концепции веб-сервиса представлена на рисунке 10.

Рис. 10. Схема реализации веб-сервиса

Пользователь взаимодействует с frontend-ом. В frontend-е реализован интерфейс, который позволяет пользователю работать с сервисом. Интерфейс представляет из себя рабочую область, слева от которой вертикально располагается меню, с помощью которого можно переключиться на необходимые сервисы и управлять ими (рис. 11). В самой рабочей области располагаются доступные в необходимой сети камеры в виде маленьких окошек, на которые можно нажать и непосредственно начать работу с конкретной выбранной камерой в новом интерфейсе (рис. 12). У каждой камеры свое количество поддерживаемых сервисов ONVIF, поэтому предварительно сервер запрашивает камеру, чтобы она вернула список поддерживаемых ею ONVIF сервисов. Все данные в frontend-е передаются в формате JSON на сервер-обработчик backend. В backend-е JSON-запрос, отправленный из frontend-а преобразуется в XML формат. Backend отправляет преобразованные XML-данные на сервер-обработчик goonvif, который исполняет запросы на низком уровне, непосредственно управляя камерой. Также необходимо отметить, что ответ сервера-обработчика возвращается в frontend цепочкой возвращаемых значений. Это нужно для обновления данных на странице веб-интерфейса в реальном времени.

Рис. 11. Схема реализации веб-сервиса

Рис. 12. Схема реализации веб-сервиса



Заключение

В ходе выполнения работы была разработана библиотека Goonvif на языке Go, соответствующая поставленным требованиям:

1. Поддержка сервисов Device, Media, Imaging, PTZ, Recording, Analytics.

2. Разработан REST API.

3. Архитектура библиотеки соответствует требованиям масштабируемости. Таким образом, добавление поддержки новых сервисов не составит труда.

4. Достигнут высокий уровень абстракции библиотеки от спецификаций xml, SOAP, WSDL. Таким образом, способ работы с данной библиотекой является простым и понятным.

В качестве демонстрации возможностей библиотеки был разработан web-сервис, осуществляющий управление PTZ-камерами.

Исходные коды разработанной библиотеки, а также различных пакетов, созданных в процессе работы для упрощения разработки доступны в git-репозиториях:

? https://github.com/yakovlevdmv/goonvif

? https://github.com/yakovlevdmv/gosoap

? https://github.com/yakovlevdmv/WS-Discovery

? https://github.com/palanjyan/WSDLCompiler-Go



Список использованных источников

1. ONVIF, "Our Mission - ONVIF". URL: https://www.onvif.org/about/mission/ (дата обращения 02.03.2018).

2. ONVIF, "Axis, Bosch and Sony announce Open Network Video Interface Forum (ONVIF) - ONVIF". URL: https://www.onvif.org/pressrelease/axis-bosch-and-sony-announce-open-network-video-interface-forum-onvif/ (дата обращения 02.03.2018).

3. Psialliance ,"Physical Security Interoperability Alliance PSIA". URL: https://www.psialliance.org/index.html (дата обращения 03.03.2018).

4. ONVIF, "ONVIF Doc Map". URL: https://www.onvif.org/specs/DocMap.html (дата обращения 04.03.2018).

5. ONVIF, "ONVIF™ Core Specification", Version 17.12. URL: https://www.onvif.org/specs/core/ONVIF-Core-Specification-v1712.pdf (дата обращения 04.03.2018).

6. PSIA, "Physical Security Interoperability Alliance Service Model", Version 1.2. URL: http://www.psialliance.org/documents/PSIA-Service-Model_v1_2dFinal.pdf (дата обращения 07.03.2018).

7. W3.org , "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)". URL: https://www.w3.org/TR/soap12-part1/ (дата обращения 01.01.2018).

8. OASIS, " Web Services Security: SOAP Message Security 1.1". URL: https://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf (дата обращения 31.12.2017).

9. ONVIF, "ONVIF™ Application Programmer's Guide", Version 1.0. URL: https://www.onvif.org/wp-content/uploads/2016/12/ONVIF_WG-APG-Application_Programmers_Guide-1.pdf (дата обращения 10.03.2018).

10. OASIS, " Web Services Security: UsernameToken Profile 1.1". URL: https://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf (дата обращения 11.03.2018).

11. OASIS, "OASIS Web Services Dynamic Discovery (WS-Discovery) Version 1.1". URL: http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html (дата обращения 11.03.2018).

12. ONVIF, "ONVIF™ Network Video Transmitter Device Definition", Version 2.1. URL: https://www.onvif.org/specs/td/nvt/ONVIF-NVT-Definition-v210.pdf (дата обращения 20.01.2018).

13. ONVIF, " DeviceService WSDL". URL: https://www.onvif.org/ver10/device/wsdl/devicemgmt.wsdl (дата обращения 01.01.2018).

14. ONVIF, "PTZ Service WSDL". URL: https://www.onvif.org/ver20/ptz/wsdl/ptz.wsdl (дата обращения 10.11.2017).

15. ONVIF, "Media Service WSDL". URL: https://www.onvif.org/ver10/media/wsdl/media.wsdl (дата обращения 10.11.2017).

16. Node.js Foundation, "Node.js". URL: https://nodejs.org/en/ (дата обращения 10.03.2018).

17. Facebook Inc., "React - A JavaScript library for building user interfaces". URL: https://reactjs.org/ (дата обращения 20.03.2018).

18. "Babel - The compiler for writing next generation JavaScript". URL: https://babeljs.io/ (дата обращения 20.03.2018).

"webpack documentation". URL: https://webpack.js.org/concepts/ (дата обращения 20.03.2018). Размещено на Allbest.ru

...