πŸ“œ ⬆️ ⬇️

Integrating two video surveillance systems: Axxon Next and SureView

Edison Software programmers were tasked with developing software components that enable interaction between Axxon Next and Immix. SureView service is very popular in the UK, and in order to strengthen its position in the video surveillance market, Axxon Next (ITV) developers decided to make a tricky strategic move and integrate, giving the order to outsource Edison Software. It took 316 hours to develop and debug the integration plugin.

image

Axxon Next is a product of the Russian company ITV, which is a developer of software for security systems and video surveillance.
')
Axxon Next is a high-performance video surveillance system with an intuitive user interface that supports more than 6000 IP-device names and allows you to build easily scalable video surveillance systems of any complexity. It should be noted that the full functionality of the system is included in any license, even if it contains only one camera.

Immix software is a product of the American company SureView systems and is a video-oriented software platform designed to receive alarm events from video surveillance systems, access control, automation platforms and situational information systems.

The result of the development was to be a plug-in for the SureView software, which allows the following features of the Axxon Next software to be used from the SureView software.


SureviewSystems


image

To implement plug-ins for SureView software, SureviewSystems provides an API with documentation and an application for testing the plugin being developed.

An API is a large number of different interfaces that describe the various functionalities of an integrated device.

Examples

1) In order for the SureView software to connect to an integrable device, you need to implement the following interface.

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

2) In order for SureView software to play back a live video stream from an integrated device, you need to implement such an interface.

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

To speed up development with the SDK, the base class StreamCam is supplied, which already implements a part of the required interfaces and can play the RTSP stream; you simply need to specify a link to the video stream being played.

Axxonnext


image

To manage devices connected to the Axxon Next server, the latter provides a fairly convenient and simple API.

Description API can be found here .

Device management occurs via the HTTP protocol, for security, Http Basic authorization is used.

All AxxonNext server responses are sent in Json format.

Consider an example of playing a live stream and telemetry control. To get a list of connected devices, just send a request: GET / video-origins.

In response to this request, the Axxon server will send a list of connected devices.

 { "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]" } } 

In addition to the device name, the response also contains additional information about the device: the device state is the state field, its name is the friendlyName field.

The name of the device consists of three components.

  1. The host name where the AxxonNext server is installed. In the example presented, this is HOSTNAME . This information is necessary due to the fact that many Axxon servers can be combined into a single domain, and device management is possible through one single Axxon server.
  2. The name of the connected device. In this example, these are DeviceIpint.4 and DeviceIpint.5.
  3. The name of the original video source. In this example, this is SourceEndpoint.video.
  4. One device can have several video signal sources, for example, with different quality.

To request all video sources of the device, you must send a request that has the following form:

 GET /video-sources/HOSTNAME/DeviceName/OriginSource 

where HOSTNAME , DeviceName and OriginSource are the previously described 3 components of the device name.

To receive a live stream (in RTSP format) from a specific signal source, you must send the following request.

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

In response, we will get a link to the RTSP stream we need.

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

To get a list of telemetry devices for the original video source, you must send a request of the form:

 GET /control/telemetry/list/HOSTNAME/DeviceName 

where HOSTNAME and DeviceName are the previously described host name and device name.

In response, we will receive a list of telemetry devices available on the device.

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

The device name also consists of three components, the last of which is the name of the telemetry device, and the first two are the previously described host name and device name.

Before starting to control the device, it is necessary to make a request for information about the control methods supported by the device. This is done using a query that has the following form.

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

In response, we will receive information on the degrees of freedom, limiting values ​​and methods of controlling the device.

 { "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 - information about degrees of freedom with maximum permissible values ​​in degrees:


Each degree of freedom contains a list of supported control methods:


To start the session of controlling the telemetry device, it is necessary to capture the session of the control by sending a request of the form

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

where n is a number from 1 to 5, the priority of the management session.

If the telemetry device is currently free or is being controlled by another user with a lower priority, control is seized and the following response comes from the server:

 { "session_id" : [id] } 

where id is the session id .

To maintain the relevance of the session management, you must send requests at least once every 10 seconds.

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

To release the session, you must send a request of the following form.

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

To send a command to change one of the degrees of freedom of telemetry, you must send a request of the form:

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

Where:


The main difficulty in the implementation of the project was the implementation of the transmission of alarm messages from AxxonNext to SureView.

Difficulties.

  1. The SureView integration plugin cannot query the alarm list, the corresponding functionality is simply not provided in the SDK. Instead, the SDK assumes that the alarm messages will come to the SureView software via SMTP protocol, and then the integration plugin will then (according to the SDK) analyze the message body and extract necessary information from it, such as: camera number and name or the sensor on which the alarm was generated.

  2. AxxonNext does not send alarm event lists, but sends them on request via the HTTP API. Selection of events is carried out for a specified period of time. To its credit, the AxxonNext software can send events via the SMTP protocol, but this action is configured manually, individually for each connected device, otherwise with a large number of devices and alarms you will receive spam messages.

To get out of this situation, it was decided to implement a separate service as a Windows service, which periodically reads the alarm list and sends them via SMTP to SureView software.

For more precise control of the sent list of alarms, the possibility of flexible adjustment of the parameters of the service being started was implemented with the ability to filter by devices and event types.

In addition, to prevent the event from being sent again, the service performs the control function: whether the event was sent earlier or not.

image

More projects:


How to create software for a microtomograph for 5233 man-hours
SDK for the introduction of support for e-books in FB2 format
Control access to electronic documents. From DefView to Vivaldi
Integrating two video surveillance systems: Axxon Next and SureView
Read more about the development of x-ray tomograph software
Sphere: how to monitor billions of kilowatt-hours
Developing a simple plugin for JIRA to work with a database
To help DevOps: a firmware builder for network devices on Debian for 1008 hours
Windows Service Auto Update for Poor AWS

Source: https://habr.com/ru/post/317290/


All Articles