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



Оглавление

Введение

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

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

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

  1. Обзор предметной области
  2. Долгое время проблема совместимости 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. Сравнительный анализ ONVIF и PSIA
    2. В основе стандарта 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.

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

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

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

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

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

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

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

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

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

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

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

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

              1. Реализация следующих сервисов ONVIF:
                • Device Management;
                • Media;
                • Imaging.
                  1. Реализация REST API для взаимодействия с библиотекой независимо от выбранного языка программирования;
                  2. Реализация стандарта динамического обнаружения устройств «Web Services Dynamic Discovery»: реализация отправки multicast запросов и получение ответов.

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

              1. Реализация следующих сервисов ONVIF:
                • PTZ;
                • Recording;
                • Analytics.
                  1. Разработка веб-сервиса, демонстрирующего функциональные возможности библиотеки.
                  2. Реализация стандарта динамического обнаружения устройств «Web Services Dynamic Discovery»: генерация запросов, в соответствии с [11].

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

              1. Проектирование архитектуры библиотеки.
              2. Тестирование библиотеки
              3. Реализация высокоуровневых функций, упрощающих выполнение рутинных процедур, которые не определены в стандарте ONVIF.
              4. Реализация высокоуровневых функций для упрощения процесса видеосъемки.
                1. Процесс разработки библиотеки
                  1. Реализация SOAP

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

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

                1. Реализация ONVIF сервисов
                2. Из документа 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 приведены в следующем разделе.

                  1. Реализация WS-Security
                  2. Авторизация между клиентом и устройством осуществляется посредством спецификации 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

                    1. Реализация WS-Discovery
                    2. Стандарт 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.

                      1. Разработка высокоуровневых функций
                      2. Стандарт 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().

                        1. Описание работы с библиотекой
                        2. Библиотека 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")

                          вернет нулевой объект камеры и ошибку:«cameraisnotavailableat 127.0.0.1:80oritdoesnotsupportONVIFservices».

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

                          Листинг 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. Фрагмент ответа от камеры

                          • Довериться б