Access architecture {#architecture}
Access scheme {#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 designed to store relationships between ACS (Access Control System) individuals and their biometric data. Enables synchronization of data between access control systems, biometric systems (LP, CBS), and external services. The storage contains: employee ID in the ACS, full name, card number, and the last photo update timestamp. |
| 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 {#diagrams}
Interaction of internal components of Access {#internal-interaction}
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-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 {#monitoring-automatic}
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. |