IREXDocs
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

The diagram uses earlier service names: channel-processor corresponds to channel-manager, and eventsproxy corresponds to va-events-receiver.

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

Stores analytics events, JPEG event frames, and archive-part metadata. The metadata identifies each video part and its S3 object key; video bytes are stored in S3-compatible object storage.

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

Stores recorded video as fragmented MP4 (fMP4) parts, uploaded gallery files, and exported archive files. JPEG event frames are stored in Cassandra.

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).

Channel Manager

Creates, updates, and removes gochannel pods according to the channel configuration stored in PostgreSQL.

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.

Event Receiver

The va-events-receiver service receives analytics events through va-api-gateway and publishes them to Kafka. Video recording is a separate path: gochannel writes fMP4 parts to S3-compatible storage.

Receives batches of analytics events from the channel runtime.

Outputs event messages.

Snapshots Microservice

Stores JPEG event frames in Cassandra and retrieves them 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.