IREX
EN

Microservice architecture

On the software implementation level, IREX can be considered an aggregation of microservices interacting with each other according to the simplified scheme below:

Diagram of IREX microservices: a user's browser queries nginx and edge-api, which connect to go-channel video analytics, eventsearch, eventproxy, facelist-matcher, platelist-matcher, Kafka, kafka-cassandra-streamer, kafka-ignite-streamer, channel-status, channel-processor, snapshots, PostgreSQL, Cassandra, Ignite, and S3

Here, the two basic sub-platforms can be outlined:

  • Private Cloud
  • Smart City

The cloud-native architecture like this exploits the flexibility, scalability, and resilience of cloud computing to allow secure, resilient, and easy deployment in any datacenter or on-prem location.

Secure cloud

The Secure Cloud runs 100% open-source software to supply the following services to the Smart City:

Cassandra

A distributed database to store raw video data coming in from external sensors and return those in response to users' queries for playback or other actions.

Redis

A resident NoSQL database system storing Key-Value pairs relevant to channel statuses and authentication sessions; used as a fast-access cache.

Kafka

Distributed message broker between all the other microservices.

S3

Object storage for snapshots and video chunks.

PostgreSQL

Relational database inside Kubernetes to supply various information to all the other components.

The Smart City

The Smart City sub-platform implements data processing based on K8S (Kubernetes).

K8S (Kubernetes) is a system for deploying and managing (orchestrating) docker containers, providing mechanisms for self-recovery, performance verification, task re-planning, and load balancing during data processing. Its main task is to run the container on server hardware with sufficient resources (CPU, RAM). Available resources are counted based on the requested resources in the POD and the server capacity. Kubernetes automatically restarts the application when it crashes. When a Kubernetes machine crashes, the containers are migrated to available machines.

channel-status Checker

Checks channel statuses to display those graphically on the map.

Inputs channel ID list.

Outputs channel status (optionally - reason for it, e.g. status = unhealthy, reason = FrameRateTooLow).

сhannel-processor Manager

Provides Kubernetes PODs to the channels, updates the channels, and manages S3 bucket quotas.

Inputs requests to update the channels.

Outputs the updated channel list.

API edge-api

Processes HTTP requests from the users sent via the web interface to respond with the processing results.

kx-channel analytics module

Implements video input, processing it with video analytics to generate events archiving those and other major functions.

Inputs user's commands, such as "Set reference frame", "Reload video analytics settings", etc.

Outputs events and event snapshots.

eventproxy interface

Sends event messages to Kafka and records video chunks to Cassandra.

Inputs events and event snapshots from kx-channel.

Outputs event messages.

snapshots microservice

Stores snapshots to provide those to the user on request.

Inputs requests for snapshots.

Outputs the snapshots.

facelists-matcher module

Compares calculated face descriptors against those enrolled in the database.

Inputs detected face descriptors.

Outputs the "Match <...>" events.

platelists-matcher module

Compares detected plate numbers against those enrolled in the database.

Inputs detected plate numbers.

Outputs the "Match <...>" events.

API eventsearch

Implements the search for user-defined events in the database.

Inputs query for events conditions.

Outputs the events.

kafka-cassandra-streamer microservice

Dispatches full event messages to Cassandra.

Inputs event messages from Kafka.

Outputs events saved to Cassandra.

kafka-ignite-streamer microservice

Dispatches event metadata messages to Ignite.

Inputs event messages from Kafka.

Outputs event metadata saved to Ignite.

Extras

Additionally, there are services and utilities implemented on the Smart City sub-platform yet not shown on the scheme. The most important of them are:

alarm-monitor

The service to manage alarm monitors.

Archive-streamer5

Streams the requested video fragments on the UI.

authentication-server

Implements user authentication to provide access according to their roles.

descriptor-extractor

The neural network to calculate face descriptors.

descriptor-updater

Updates a face descriptor if a more similar match is found in the database.

downloader

Downloads user-defined video fragments to the local files.

edge-to-cloud-connector, edge-from-cloud-connector

Gates to communicate with kx-channel through edge-api.

ignite-cleaner

Cleans the outdated entries in Ignite database

ignite-instance

The Ignite database instance to store event metadata.

Ignite-tools

Ignite management script storage.

kafka-init

Creates message topics in Kafka.

license-postgres

License to the platform database.

license-server

The server to manage licenses (issue, update, terminate).

ptz

PTZ camera control (rotate, shift, zoom).

raw-video-channel-processor

Creates a channel for a video uploaded from an external file.

seclog

Complete logging of major system performance events, including who did what, in full detail to ensure transparency and responsibility principles as CJIS and GDPR stipulate.

stream-info

Video stream properties provider (resolution, bitrate, etc.).

sql-migrations

The PostgreSQL migration tool.

sync-event-streamer

Passes PostgreSQL entry messages to Kafka.

va-event-processor

The neural network to detect appearance features, such as beard, glasses, mask or no mask.

Edge server architecture

Edge server architecture allows the video analytics resources to be deployed on edge servers located close to the cameras on a remote site.

Diagram of edge server architecture: two remote sites with edge clusters receiving RTSP video from cameras and storing video locally, each sending events to a central datacenter cloud cluster that serves the user, with video transmitted on demand

The basic idea is that with video analytics executed directly on the remote site, there is no need to transmit the entire raw video stream from the cameras into the cloud via a broadband TCP-IP link; only the analytics products - events, which are of major concern for the end-user - can be transmitted making the traffic much smaller and easing the bandwidth requirements. Of course, whenever queried for, video can be transmitted to the data center; however, on-demand transmissions take much less traffic than the continuous one.

The table below gives a summary of cloud-based analytics versus edge server-based one in order to prove the edge server solution is less resource-consuming as for bandwidth and hardware yet more robust to disruptions on the Internet and tough external conditions (humidity, air purity in server rooms).

Feature Cloud-based analytics Edge server-based analytics
Real-time alerts for control rooms and fusion centers YES YES
Multi-site Searchveillance™ YES YES
Reduced bandwidth NO YES
Offline video analytics and recording NO YES
Automatic event synchronization upon network recovery NO YES
Centralized management YES YES
High availability, load balancing, fail-over Included Extra cost for on-prem hardware
Video and event encryption YES (VPN required) YES (automatic VPN)
Automatic software updates YES YES
Automatic camera discovery NO YES

The solution can be recommended wherever lower bandwidth matters, Internet disruptions seem likely, and/or external conditions are tough. If this is the case, order a calculation from the Platform representative of what hardware the edge server-based solution needs, and an estimate of costs.

If implemented, the edge servers can then be managed.