Architecture and data flow – Milestone Analytics 2.2 Generic VA Interface User Manual
Page 7

Milestone XProtect Analytics 2.2 Generic VA Interface; Developer’s Manual
www.milestonesys.com
Page 7
Architecture & Data Flow
Architecture and Data Flow
The overall architecture is as follows: for each concrete VCA system, a driver is developed which
acts as the glue between the analytics system and the Milestone analytics framework. This driver
must implement a certain interface, and can thereby be plugged into the analytics server, which is
responsible for loading the plugin at runtime.
Milestone XPA 2.2 overall architecture and dataflow. Drivers, analog to the video camera drivers, connect the
underlying VCA systems with the analytics server. For a larger version of the illustration, see Appendix A.
The plugin is completely responsible for controlling the communication with the underlying
analytics system, and is the only runtime component in which vendor specific information is
implemented.
In general, VCA systems are distributed in one of the following ways:
As a complete, standalone server system (server-based)
As a library which must be built into software (library-based)
As part of the firmware on the device (edge-based)
Some systems have analytics put on both the edge and on the server, where a pre-processing is
done on the camera and the server handles the core part of the processing. However, in this
context, the server would still be our point of entry, and the analytics framework would not do
anything about the pre-processing on the edge.
In the above figure, the three different types of analytics are denoted by the X, Y and Z. In version
2.2 of the analytics framework, only real-time alerts are handled. This means that metadata in
general is not collected and stored. This will be handled in later versions.