Access architecture#
Access scheme#
The Access scheme is shown below (Figure 1).
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. |
| JSON-storage | settings.json file to store integration settings and user data. |
| Worker | A set of modules for interacting with external components. |
| Pipelines Module | Access module that contains libraries for configuring the operation of external devices and external services |
| 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, card readers) 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).
Table 4. Sequence diagram description
| Step | Description |
|---|---|
| (1) | The man approached the turnstile with the purpose of passage, the person's face was detected by the terminal. |
| (2) | The terminal sent a photo of a person to the "Devices" module |
| (3) | The Device module sends face data to the Pipeline module for further processing. |
| (4) | The Pipeline module processes photos according to internal settings. |
| (5) | The Pipeline module passes the pass data to the Service module for further processing. |
| (6) | The Service module sends a request to an external service (LP5) to identify a person. |
| (7) | External service (LP5) performs identification. |
| (8) | External service (LP5) returns a response about the result of face recognition and identification. |
| (9) | The Services module sends recognition data to the Pipeline module. |
| (10) | The Pipeline Module returns a response to the Device Module about the recognition result. |
| (11) | The Device Module returns the name data of the person at the terminal to display the name and successful identification message on the terminal screen |
| (12) | The Pipeline module sends recognition data to the Services module to the Pipeline module. |
| (13) | The Services module passes recognition data to External services (Sigur) |
| (14) | External service (Sigur) processes the recognition result according to internal instructions. In 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 sends processing data to the Pipeline module. |
| (17) | The Pipelines module sends a request to Redis to save the pass data to the JSON-storage. |
| (18) | Redis creates a task to store information in the JSON-storage. |
| (19) | Redis passes the task to the Access backend server for implementation |
| (20) | Access backend server sends data to the JSON-storage to store information about the pass. |
| (21) | Access backend server sends data to the Access UI to display the result of the pass to the logging section. |
| (22) | Access backend server returns information about the execution of a task to Redis. |
Creating a component#
Creating a component in Access UI (Figure 3).
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).
Table 6. Sequence diagram description
| Step | Description |
|---|---|
| (1) | The entry point for this process is the creation of any component. |
| (2) | Access backend server passes data about the created bean to Redis. |
| (3) | Redit sends a request every minute to connected Modules to check the status of external devices. |
| (4) | Modules redirect the connection check request to external components. |
| (5) | External components return a response about the connection status, if the response to the request was not received, then the module considers the connected device disconnected. |
| (6) | The module returns a response about the state of the component. |
| (7) | Redis passes the state of the components to the Access backend server. |
| (8) | Access backend server sends data to the JSON-storage to store component information. |
| (10) | Access backend server sends data to the Access UI to display the component's activity status. |
| (11) | Access UI updates the component's activity status indicator. |
| (12) | Access UI returns a status update response to the Access backend server. |
Manual monitoring#
Manual monitoring of the task list using Flower (Figure 5).
Table 7. Sequence diagram description
| Step | Description |
|---|---|
| (1) | The user sends a request to the Flower monitoring component to get a list of tasks and task status. |
| (2) | Flower sends a request for a list of tasks and their status to the Rabbit MQ queue manager. |
| (3) | Rabbit MQ returns information about the tasks in the response. |
| (4) | Flower displays a list of tasks for the user. |
For monitoring instructions, see Monitoring internal tasks with Flower