Интегрируем две системы видеонаблюдения: Axxon Next и SureView

Перед программистами Edison Software была поставлена задача — разработать программные компоненты, обеспечивающие взаимодействие между ПО Axxon Next и Immix. Сервис SureView очень популярен в Великобритании, и дабы укрепить свои позиции на рынке видеонаблюдения, разработчики Axxon Next (ITV) решили совершить хитрый стратегический ход и интегрироваться, отдав исполнение заказа на аутсорс компании Edison Software. На разработку и отладку плагина интеграции ушло 316 часов.

ПО Axxon Next является продуктом российской компании ITV, являющейся разработчиком программного обеспечения для систем безопасности и видеонаблюдения.

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

ПО Immix является продуктом американской компании SureView systems и представляет собой видео-ориентированную программную платформу, предназначенную для приема тревожных событий из систем видеонаблюдения, контроля доступа, платформ автоматизации и ситуационных систем информирования.

Результатом разработки должен был стать плагин для ПО SureView, предоставляющий возможность использования из ПО SureView следующих возможностей ПО Axxon Next.

• Отображение в ПО SureView живого видео от ПО Axxon Next.
• Проигрывание и управление проигрыванием в ПО SureView архива видео, хранящегося под управлением ПО Axxon Next.
• Управление из ПО SureView поворотными (PTZ) устройствами, подключенными к ПО Axxon Next, включая использование предустановок (Presets).
• Получение в ПО SureView событий о возникших тревожных сообщениях от ПО Axxon Next.

SureviewSystems

Для реализации плагинов для ПО SureView компанией SureviewSystems предоставляется API с документацией и приложение для тестирования разрабатываемого плагина.

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

Примеры.

1) Чтобы ПО SureView могло соединяться с интегрируемым устройством, необходимо реализовать следующий интерфейс.

 public interface IDeviceConnectDisconnect : IDevice     {         void DeviceConnect();         void DeviceDisconnect();     }

2) Чтобы ПО SureView могло воспроизвести живой видеопоток с интегрируемого устройства, необходимо реализовать такой интерфейс.

public interface ICamera : IDevice     {         void CameraStartLive();         void CameraStop();     }

Для ускорения разработки с SDK поставляется базовый класс StreamCam, который уже реализует часть необходимых интерфейсов и умеет воспроизводить RTSP-поток, достаточно просто указать ссылку на воспроизводимый видеопоток.

AxxonNext

Для управления устройствами, подключенными к серверу Axxon Next, последний предоставляет достаточно удобное и простое API.

Описание API можно посмотреть тут.

Управление устройствами происходит по протоколу HTTP, для обеспечения безопасности используется Http Basic авторизация.

Все ответы сервера AxxonNext отправляются в формате Json.

Рассмотрим пример воспроизведения живого потока и управления телеметрией. Для получения списка подключенных устройств достаточно послать запрос: GET /video-origins.

В ответ на этот запрос сервер Axxon отправит список подключенных устройств.

{       "HOSTNAME/DeviceIpint.4/SourceEndpoint.video:0:0":       {         "origin": "SALES/DeviceIpint.4/SourceEndpoint.video:0:0"         ,"state": "signal_restored"         ,"friendlyNameLong": "4.IP устройство [4]"         ,"friendlyNameShort": "IP устройство [4]"       }       ,"HOSTNAME/DeviceIpint.5/SourceEndpoint.video:0:0":       {         "origin": "SALES/DeviceIpint.5/SourceEndpoint.video:0:0"         ,"state": "disconnected"         ,"friendlyNameLong": "5.IP устройство [5]"         ,"friendlyNameShort": "IP устройство [5]"       }     }

В ответе помимо названия устройства также содержится дополнительная информация об устройстве: состояние устройства — поле state, его имя — поле friendlyName.

Название устройства состоит из трех компонентов.

1. Имя хоста, на котором установлен сервер AxxonNext. В представленном примере это HOSTNAME. Данная информация необходима в связи с тем, что множество серверов Axxon могут быть объединены в единый домен, и управление устройствами возможно через один единый сервер Axxon.
2. Имя подключенного устройства. В данном примере это DeviceIpint.4 и DeviceIpint.5.
3. Имя оригинального источника видео. В данном примере это SourceEndpoint.video:0:0.
4. У одного устройства может быть несколько источников видеосигнала, например, с различным качеством.

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

GET /video-sources/HOSTNAME/DeviceName/OriginSource

где HOSTNAME, DeviceName и OriginSource — ранее описанные 3 компонента названия устройства.

Для получения живого потока (в формате RTSP) от конкретного источника сигнала необходимо послать следующий запрос.

GET /live/media/HOSTNAME/DeviceName/VideoSource?format=rtsp

В ответ получим ссылку на нужный нам RTSP поток.

{      "rtsp":{         "description":"RTP/UDP or RTP/RTSP/TCP",         "path":"hosts/SALES/DeviceIpint.4/SourceEndpoint.video:0:0",         "port":"554"         }     }

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

GET /control/telemetry/list/HOSTNAME/DeviceName

где HOSTNAME и DeviceName — описанные ранее имя хоста и имя устройства.

В ответ получим список устройств телеметрии, доступных на устройстве.

[         "SALES/DeviceIpint.5/TelemetryControl.0"     ]

Имя устройства так же состоит из трех компонентов, последний из которых — имя устройства телеметрии, а первые два — описанные ранее имя хоста и имя устройства.

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

GET /control/telemetry/info/HOSTNAME/DeviceName/TelemetryName

В ответ получим информацию о степенях свободы, предельных значениях и способах управления устройством.

{         "degrees": {             "tilt": {                 "relative": {"min": "-45", "max": "45"},                 "continuous": {"min": "-10", "max": "10"}             },             "pan": {                 "absolute": {"min": "-170", "max": "170"},                 "continuous": {"min": "-10", "max": "10"}             },             "zoom": {                 "absolute": {"min": "0", "max": "20"}             }         },     "feature": ["autoFocus", "areaZoom", "pointMove"]     }

Degrees — информация о степенях свободы с предельно допустимыми значениями в градусах:

• tilt — управление наклоном видеокамеры;
• pan — управление поворотом видеокамеры;
• zoom — управление зумом;
• focus — управление фокусом;
• iris — управление диафрагмой.

Каждая степень свободы содержит список поддерживаемых способов управления:

• absolute — абсолютный — поворот камеры на заданный угол относительно установки камеры;
• relative — относительный — поворот камеры на заданный угол относительно текущего положения камеры;
• continuous — непрерывный — непрерывный поворот камеры пока нажата кнопка управления;
• feature — список поддерживаемых функций, задача реализации этих функций в плагине интеграции не стояла.

Для начала сессии управления устройством телеметрии необходимо произвести захват сессии управлении, послав запрос вида:

GET /control/telemetry/session/acquire/HOSTNAME/DeviceName/TelemetryName?session_priority=n

где n — число от 1 до 5, приоритет сессии управления.

Если в данный момент устройство телеметрии свободно или им управляет другой пользователь с меньшим приоритетом, то происходит захват управления, и от сервера приходит такой ответ:

     {         "session_id" : [id]     }

где id — идентификатор сессии.

Для поддержания актуальности сессии управления, необходимо не реже чем раз в 10 секунд отправлять запросы.

GET /control/telemetry/session/keepalive/HOSTNAME/DeviceName/TelemetryName?session_id=id

Для освобождения сессии необходимо послать запрос следующего вида.

GET /control/telemetry/session/release/HOSTNAME/DeviceName/TelemetryName?session_id=[id]

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

GET /control/telemetry/DEGREE/HOSTNAME/DeviceName/TelemetryName?mode=MODE &value=VAL&session_id=id

где:

• DEGREE — название степени свободы: tilt, pan, zoom, focus, iris;
• MODE — способ управления: absolute, relative, continuous;
• VAL — значение, на величину которой необходимо изменить или установить степень свободы;
• id — идентификатор сессии управления.

Основной сложностью при реализации проекта оказалась реализация передачи тревожных сообщений из AxxonNext в SureView.

Сложности.

1. Плагин интеграции SureView не может произвести запрос списка тревожных сообщений, соответствующего функционала попросту не предусмотрено в SDK. Вместо этого SDK предполагает, что тревожные сообщения будут приходить в ПО SureView по протоколу SMTP, и уже потом плагин интеграции будет заниматься (в соответствии с SDK) разбором тела письма и выделением из него необходимой информации, такой, например, как: номер и имя камеры или датчика, на котором был сгенерирован сигнал тревоги.
2. ПО AxxonNext не отправляет списки тревожных событий, а отдает их по запросу посредством HTTP API. Выборка событий осуществляется за заданный период времени. К чести ПО AxxonNext, оно умеет отправлять события по протоколу SMTP, но данное действие настраивается вручную, индивидуально для каждого подключенного устройства, иначе при большом количестве устройств и тревог получится спам-рассылка.

Для выхода из сложившейся ситуации было решено реализовать отдельный сервис в виде службы Windows, которая занимается периодическим считыванием списка тревог и отправкой их по протоколу SMTP в ПО SureView.

Для более точного контроля отправляемого списка тревог была реализована возможность гибкой настройки параметров запускаемого сервиса с возможностью фильтрации по устройствам и типам событий.

Кроме того, для предотвращения повторной отправки событий сервис выполняет функцию контроля: было ли отправлено событие ранее или нет.

Больше проектов:

• Как за 5233 человеко-часа создать софт для микротомографа
• SDK для внедрения поддержки электронных книг в формате FB2
• Управление доступом к электронным документам. От DefView до Vivaldi
• Подробнее о разработке софта рентгеновского томографа
• «Сфера»: как мониторить миллиарды киловатт-часов
• Разработка простого плагина для JIRA для работы с базой данных
• В помощь DevOps: сборщик прошивок для сетевых устройств на Debian за 1008 часов
• Автообновление службы Windows через AWS для бедных

ссылка на оригинал статьи https://habrahabr.ru/post/317290/