Access architecture#
Access scheme#
The Access scheme is shown below (Figure 1) and (Table 3).
Table 3. Scheme description.
| Component | Description |
|---|---|
| Users | The system administrator configures and maintains Access. |
| Access | A set of management software tools that allow for the collaboration of VisionLabs products and various access control and management systems (ACS). |
| Access UI | Access graphical user interface. |
| Access BackEnd | BackEnd Access, responsible for working with external components, interaction with the UI. |
| Access backend server | A set of libraries that combines Access and UI modules. |
| Rabbit MQ | Message queue broker. |
| Redis | A system for storing data in the form of structures to ensure the performance of Access. |
| PersonStorage | Local storage storing the connection between ACS personalities and their biometric data. Used for data synchronization between access control systems and biometric systems (LP, KBS) or external services. |
| JSON-storage | settings.json file to store integration settings and user data. |
| Worker | A set of modules for interacting with external components. |
| Pipeline module | Access module, which provides the basic logic and interaction of modules. |
| Devices Module | Access module that contains libraries for connecting external devices to Access |
| Services Module | Access module that contains libraries for connecting external services to Access |
| Controllers Module | Access module that contains libraries for working with external controllers |
| External devices | Connectable cameras, terminals, and thermal imaging cameras that transmit a video stream for further processing. For a complete list of available devices, see the User Manual |
| External services | PACS or VisionLabs products that can be used in integration. For a complete list of available PACS or VisionLabs products, see the User Manual |
| External controllers | External controllers (for example, converters for ACS controllers) used in integrations. |
Sequence diagrams#
Interaction of internal components of Access#
Interaction of Access components on the example of typical integration of video signal source + LP5 + Sigur (Figure 2) and (Table 4).
Table 4. Sequence diagram description
| Step | Description |
|---|---|
| (1) | A person approached the turnstile intending to pass, and the terminal captured the person's face. |
| (2) | The terminal transmitted the person's photo to the Devices module. |
| (3) | The Devices module sends the face data to the Pipeline module for further processing. |
| (4) | The Pipeline module processes the photo according to its internal settings. |
| (5) | The Pipeline module transmits the passage data to the Service module for further processing. |
| (6) | The Service module sends a request to the external service (LP5) for face identification. |
| (7) | The external service (LP5) performs the identification. |
| (8) | The external service (LP5) returns a response with the results of the face recognition and identification. |
| (9) | The Services module transmits the recognition data to the Pipeline module. |
| (10) | The Pipeline module returns the recognition result to the Devices module. |
| (11) | The Devices module sends the person's name data to the terminal for displaying the name and a message about successful identification on the terminal screen. |
| (12) | The Pipeline module transmits the recognition data to the Services module. |
| (13) | The Services module transmits the recognition data to the external service (Sigur). |
| (14) | The external service (Sigur) processes the recognition result according to its internal instructions. In the case of successful recognition, it sends a signal to open the turnstile. |
| (15) | The external service (Sigur) returns the processing result to the Services module. |
| (16) | The Services module transmits the processing data to the Pipeline module. |
| (17) | The Pipeline module transmits the data to the Access backend server using RabbitMQ. |
| (18) | The Access backend server sends data to the Access UI for displaying the passage result in the Logging section. |
Creating a component#
Creating a component in Access UI (Figure 3) and (Table 5).
Table 5. Sequence diagram description
| Step | Description |
|---|---|
| (1) | The user fills in the data of a new object (device, service, pipeline, or controller) in the Access UI. |
| (2) | Access UI sends a request to the Access backend server to create a component. |
| (3) | Access backend server creates the component and generates a task to check the status of the connected component. |
| (4) | Access backend server sends a task to Rabbit MQ to enqueue the task. |
| (5) | Rabbit MQ returns the response that the task has been queued. |
| (6) | Rabbit MQ sends a request to check the status of the component to the appropriate module (Devices/Services/Controllers) specified in the component's settings. |
| (7) | The Devices/Services/Controllers module redirects the status check request to an external device/service/controller. |
| (8) | External device/service/controller returns an activity status response. |
| (9) | The Devices/Services/Controllers module returns a response about the state of the external device/service/controller. |
| (10) | Alt pipeline creation. Rabbit MQ sends a request to the Pipeline Module to check the status of the components specified in the pipeline settings. |
| (11) | Alt pipeline creation. The Pipeline module redirects the status check request to the Devices/Services/Controllers modules specified in the pipeline settings. |
| (12) | Alt pipeline creation. The Devices/Services/Controllers modules return a response about the availability of components. |
| (13) | Alt pipeline creation. The Pipeline module returns a status response. |
| (14) | Rabbit MQ returns the result of the task to the Access backend server. |
| (15) | Access backend server sends data to the JSON-storage to save information about the pass. |
| (17) | Access backend server sends data to the Access UI to display the result of creating the component. |
| (18) | Access UI displays the created components with an active status for the user. |
Automatic monitoring#
Automatic monitoring of the state of components (Figure 4) and (Table 6).
Table 6. Sequence diagram description
| Step | Description |
|---|---|
| (1) | The entry point for this process is the creation of any component. |
| (2) | The Access backend server transmits the data of the created component to Redis. |
| (3) | Redis sends the data of the created component to a Worker, which every minute sends a request to the connected Modules to check the status of external devices. |
| (4) | The Modules forward the connection check request to the external components. |
| (5) | The external components return a response regarding the connection status; if no response is received, the module considers the connected device to be offline. |
| (6) | The Module records the component status data in Redis. |
| (7) | The Access backend server retrieves the component status data from Redis. |
| (8) | The Access UI requests the component's activity status from the Access backend server. |
| (9) | The Access UI updates the component activity status indicator. |