Glossary#

Introduction#

The document describes the purpose and functions of the user interface of the service VisionLabs LUNA Access version 2.19.0 (hereinafter — Access), and also contains hardware and software requirements.

Access is a set of software technical controls and management tools that allows you to implement the collaboration of VisionLabs products and various access control and management systems.

Access solves the following tasks:

• adding video transmission devices with frames that LP or CBS will work with;
• adding auxiliary devices for reading data from magnetic pass cards or obtaining data on a person's temperature;
• sending requests to add/change data to the LP;
• receiving identification events;
• sending requests from LUNA PLATFORM to the PACS software about identification events;
• logging of events about an unidentified person's attempt to pass through the turnstile.

Integrations using Access, LUNA CARS/LP/CBS and external devices allow you to solve the following tasks:

• access control;
• improvement of accessibility and throughput of checkpoints;
• control of the time spent by employees, visitors, vehicles in the secure area;
• protection against unauthorized access attempts using Liveness technology.

The number of connected cameras, terminals, and turnstiles can be any and depends on the requirements for the deployed system but is limited by the license for VisionLabs products and the ACS capabilities.

Depending on the chosen solution, access control can be applied using face recognition or a magnetic pass card.

System requirements#

Software Requirements (Table 1).

Table 1. Software requirements

Workstation hardware requirements (Table 2).

Table 2. Hardware Recommendations

Supported components and versions#

Supported components#

Access allows you to add the following components to integrations (Table 3):

Table 3. Supported Components

Services version matching#

Access supports the following services and firmware versions (Table 4):

Table 4. Supported external services

Device version matching#

Access supports the following devices and firmware versions (Table 5):

Table 5. Supported devices

Supported versions of controllers and converters#

Access supports the following controllers, converters, and their firmware versions (Table 6):

Table 6. Supported controllers and converters

Working with Access#

Access Localization#

Access supports to localizations:

• English;
• Russian.

Press button рус|eng to change localization (Figure 1).

Access automatically refresh webpage and show english localization (Figure 2)

Для возврата к русскому интерфейсу нажмите на кнопку рус|eng еще раз.

User roles and permissions#

There is only one role available in Access — "administrator" (Table 7).

Table 7. List of available sections and permissions

Adding an account#

All user accounts are created by the administrator of the Access.

For a complete description of the user creation process, see the Administrator Manual.

Authorization in Access#

The user accesses Access by logging into a web browser to the site.

You need to open a web browser and go to the server where Access was installed. Example of an address: http://ip_address:9092/services.

The link to enter the Access web interface must be requested from the administrator.

The first time you sign in to Access, the Services page is launched (Figure 3).

Unauthorized users are not allowed to view and create components and logs.

For authorization in the Access, click on the to the right of the user's avatar and click on the Sign in button (Figure 4).

The authorization form will open (Figure 5).

To authorize in the Access, enter your credentials (login and password) in the appropriate fields and click the Sign in button.

The login and password are requested from the administrator of the Access.

When entering the Access, the user is taken to the Services page (Figure 6), where he can configure and add the components of the Access.

Signing out of the Access account#

To sign out of the account, click on the to the right of the user's avatar and click on the Logout button (Figure 7).

After clicking on the Logout button, the user is redirected to a page with a general view of the Access interface in a web browser, where he will not be able to configure and add Access components.

Access sections#

The user interface of the Access contains 5 sections in the main menu and 4 functions in the drop-down menu (Figure 8).

The main menu consists of the following sections:

• Services — view and create services;
• Controllers — viewing and creating controllers;
• Devices — view and create devices;
• Pipelines — view and create pipelines;
• Logging — viewing logs.

The drop-down menu consists of the following functions:

• Import settings — a function that allows you to import settings;
• Export settings is a function for exporting settings;
• Reset settings reset all settings;
• Documentation - open HTML documentation.

To expand the drop-down menu, click on the to the right of the user's avatar.

Components of the same type (Services, Controllers, Devices, or Pipelines) must have unique names (the name parameter).

Interaction with Access components occurs according to a common algorithm:

• creation of components
• getting information about the component
• grouping of components (available only for controllers and devices)
• editing a component
• component restart
• removal of a component

Creating a component#

To create a new component, do the following:

1． click on the Add component button (Figure 9);

2． a form for creating a component will open, in which you should select the type of component (Figure 10);

3． to expand the drop-down menu, click on the

on the right and select the required type of component (Figure 11);

4． a form will open for filling in the component settings, in which you should add the necessary Parameters (Figure 12);

The Parameters for configuring each component are different, see the components section.

to get information about configurable Parameters, click on the Documentation button in the upper left corner (Figure 13);

Pop-up window will display information describing the required Parameters for creating a component (Figure 14);

5． after filling in the component Parameters, click on the Save button (Figure 15).

After successful creation of the component, the message component has created successfully will appear in the upper left corner of the screen (Figure 16).

Upon successful creation, the new component should appear in the list of available components in the components section (Figure 17).

General information about the component#

The available components are displayed on the general view page of the section.

General information about the component is located in the window with a description of the component (Figure 18).

• 1 — status;
• 2 — name;
• 3 — type;
• 4 — general information ;
• 5 — additional information about Parameters.

For more information about the Parameters of the component, hover over and information will appear in a pop-up window (Figure 19).

Component grouping#

When creating a component, the user can create/select a component group.

By default, components are assigned to the "No group" group.

Component grouping allows you to visually separate components by features that interest the user: location, type, manufacturer, etc.

To create a group in the component parameters editing window:

1． click on the group input field 2． specify the group name 3． click Create (Figure 20) 4． save the component changes.

It is not recommended to enter more than 30 characters.

The component is placed in the group (Figure 21).

To add a component to an existing group:

1． go to editing the component 2． select the desired group in the group drop-down list (Figure 22) 3． save the component changes.

Editing component#

To edit the Parameters of component, do the following:

1． click on the for the selected component (Figure 23);

2． a form for editing the component will open, in which you should make the necessary changes (Figure 24).

To get a description of the component parameters, you need to go to the corresponding section.

3． click on the Save button.

After successfully editing the component, the message component has been updated will appear in the upper left corner of the screen (Figure 25).

Restarting a component#

To restart the component, click the for the selected component (Figure 26).

After a successful restart of the component, the message component has been restarted will appear in the upper left corner of the screen (Figure 27).

Component removal#

To remove an available component, do the following:

1． click on the for the selected component (Figure 28);

2． a form for editing the component will open, in which you should click on the Delete button in the lower left corner (Figure 29).

After successfully deleting the component, the message component has been removed will appear in the upper left corner of the screen (Figure 30).

Upon successful removal, the component will disappear from the list of available components in the components section.

Deleting a component also deletes its child components.

The child components are the corresponding controllers:

• Apacs service — ApacsController;
• PercoWEB service — PercoController;
• Salto service — SaltoController;
• Strazh service — StrazhController.

Logs#

The Logs section is designed to display all system logs and search for the necessary logs in the history. Receiving and displaying new logs is performed with minimal delays in near real time.

Access stores logs for the last 7 days in an internal database, after which the logs are deleted.

The general view of the Logs section is shown below (Figure 31).

In order to expand the detailed information about the target log, click on the arrow to the right of the required log (Figure 32).

The target log opens with detailed information (Figure 33).

Logs filtering#

The Logs section allows user to filter the latest logs in order to limit the display of logs on the screen (Figure 34).

Using filters, the user can quickly find the required log.

Filters available to the user in the Logs section:

• Time period — selection of time period for logging;
• Logging levels — selection of logging level (Error, Info, Warning);
• Order by — selection of logs sorting option (From old to new, From new to old).

The user needs to tick the required filter(s), and click the Filter button so that the settings are applied (Figure 35).

If the filters are applied successfully, information with logs should be displayed, considering the selected filters. (Figure 36).

To reset the selected filters, click the Reset button(Figure 37).

If necessary, you can export filtered logs. To do this, click the Export button (Figure 38). Logs are saved to the local computer in the txt format.

To collapse the Filters block, click on the arrow in the upper right corner (Figure 39).

Access function#

Import settings function#

The Import settings function is designed to import settings from the local computer to the Access.

To import the settings, follow these steps:

1． Click on the arrow in the upper right corner to the right of the user's avatar to expand the drop-down menu (Figure 40).

2． Select the "Import Settings" function in the drop-down menu (Figure 41).

3． The file export form will open, click on to select a json file (Figure 42).

4． In the "Setting name" field, the name of the imported file will be transferred; if necessary, specify the name of the loaded setting (Figure 43).

5． Click on the Add button (Figure 44).

After successfully importing the setup, the message Setup loaded will be displayed in the upper-left corner of the screen (Figure 45).

If the setting is created and imported correctly, the components contained in this setting will be displayed in the corresponding sections "Services", "Controllers", "Devices" and "Pipelines".

Export settings function#

The Export settings function is designed to export settings to a local computer from the Access.

To export the settings, follow these steps:

1． Click on the arrow in the upper right corner to the right of the user's avatar to expand the drop-down menu (Figure 46).

2． Select the Export Settings function in the drop-down menu (Figure 47).

A file with the saved settings will be downloaded to the local computer in json format with all the components that are contained in this setting.

Reset Settings function#

The Reset Settings function deletes all components and related data in the Services, Controllers, Devices and Pipelines sections.

Full name variables#

The fields for entering successful_pass_message_template allow you to display the full name of recognized faces:

If the full name has more than 30 characters, then the first name will be shortened automatically to Last name with initials.

• {fullname} - full name of the person from the "Information" field (user_data). Ivanov Petr Sergeevich;
• {lastname} - Last name of the person. This is the first word from the "Information" field. Ivanov;
• {firstname} - The name of the person. This is the second word from the "Information" field. Peter;
• {middlename} - Middle name of the person. This is the third word from the "Information" field. Sergeevich;
• {short_lastname} - The first letter of the last name with a dot at the end. I.;
• {short_firstname} - The first letter of the name with a dot at the end. P.;
• {short_middlename} - The first letter of the patronymic with a dot at the end. S. .

To display the message on the terminal screen, it is required to specify the desired variants of full name in the successful_pass_message_template and unsuccessful_pass_message fields (Table 8).

Table 8. Example of using the variables full name

Other functions#

Documentation#

The Documentation button is designed to switch to the online Access documentation.

Services#

Services in Access are required to select options for connecting to external systems.

All fields are required unless otherwise stated in the description.

Apacs#

This service is designed to interact with the APACS 3000 ACS.

Apacs functionality#

Main functions:

• adding devices that the biometric system will work with;
• receiving regular updates from the ACS software database;
• sending requests to add/change data in the local person storage;
• receiving identification events;
• sending a request to the ACS software about identiloginfication events;
• integration with LP5;
• integration with CBS: Alfa;
• logging of events about an attempt by an unidentified employee to pass through the turnstile.

Configuring parameters for connecting to the APACS ACS#

Service settings and possible values (Table 9):

Table 9. Setting up the APACS service

The master key can be found in any Apacs client application in the Help → About section.

The type of card format (card_format_source) can be found in any Apacs client application in the Console tab → System Root section → Hardware Server section → select a network driver → select a controller → Group: Card Format section → select any card format → General tab → field ""The type of the object"".

Bastion#

The service is designed to interact with Bastion ACS 2 and 3.

Bastion functionality#

Main features:

• adding devices that the biometric system will work with;
• receiving regular updates from the ACS software database;
• sending requests to add/change data in the local person storage;
• receiving identification events;
• sending requests to the ACS software about identification events;
• integration with CBS MTS;
• logging events about an attempt by an unidentified employee to pass through the turnstile.

Bastion settings#

The following settings are used when creating a new service (Table 10):

Table 10. Bastion Service Configuration

Bolid#

The service is designed to interact with the [Bolid] ACS (../bolid.md#bolid-scud).

Bolid settings#

The following settings are used when creating a new service (Table 11):

Table 11. Setting up the Bolid service

CbsAkbars#

Used to obtain a descriptor identifier in Akbars KBS from a photograph.

Configuring parameters for connecting to CbsAkbars#

Service settings and possible values ​​(Table 12):

Table 12. Configuring the CbsAkbars service

CbsAlpha#

Used to obtain a descriptor ID in Alfa CBS based on KYC. Checks if a person exists in the CbsAlpha list by KYC with the ID specified in the cbs_list_id parameter, and creates a person if KYC is not found.

Person search by KYC is performed based on the value specified in the additional field 20 of the APACS ACS employee card. The number of this field is determined by the kyc_field_number parameter in the Apacs service.

KYC data is filled in the external_id field (External ID) in LUNA CLEMENTINE 2.0.

Only LUNA PLATFORM 5.10 and newer are supported.

Setting up parameters for connecting to CbsAlpha#

Service settings and possible values (Table 13):

Table 13. Setting up the CbsAlpha service

CbsAlphaListSynchronisation#

The service is designed to synchronize two lists in CbsAlpha. The service tracks changes in the cbs list and matches them with entries from the luna list. If duplicate faces are found, the duplicate is removed from the luna list.

Configuring CbsAlphaListSynchronisation Settings#

Service settings and possible values (Table 14):

Table 14. CbsAlpha service configuration

CbsMts#

Used to retrieve the descriptor identifier in the MTS CBS from a photo.

Configuring CbsMts settings#

Service settings and possible values (Table 15):

Table 15. Setting up the CbsMts service

CbsVtb#

Used to obtain the descriptor ID in the VTB CBS by photo.

Configuring parameters for connecting to CbsVtb#

Service settings and possible values ​​(Table 16):

Table 16. Configuring the CbsVtb service

CryptoPro#

Used for signing or decrypting identification requests to a biometric system.

Main functions:

• certificate selection for signing;
• selection of the type of signature to be created;
• creation of a combined signature (contains the content to be signed and the signature);
• creation of a detached signature (signature only);
• signature verification.

Configuring parameters for connecting to CryptoPro#

Service settings and possible values ​​(Table 17):

Table 17. Configuring the CryptoPro service

EyelsProxy#

A proxy service that facilitates data transfer between the client and the controller: receives a request from the client, forwards it to the controller, obtains the response, and returns it back to the client.

Configuring parameters for connecting to EyelsProxy#

Service settings and possible values ​​(Table 18):

Table 18. Setting up the EyelsProxy service

Gate#

The service is designed to interact with Gate PACS.

Configuring Gate settings#

Service settings and possible values (Table 19):

Table 19. Gate Service Configuration

Luna#

The service is designed to redirect data from/to LP to external systems and devices.

Supported versions: 5.10 and higher.

Luna settings#

The following settings are used when creating a new service (Table 20):

Table 20. Setting up the Luna service

LunaAceConverter#

Service for sending data received from LUNA ACE devices to LP5. The received request from the device is redirected to the RRL, then a response is generated for the device based on the received response from the LP5.

Supported version LUNA ACE 1.2.23

LuaAceConverter settings#

The following settings are used when creating a new service (Table 21):

Table 21. Setting up the LUNA ACE service

Setting up LUNA ACE#

1． Connect to the device via SSh.

2． Open the file: vi /opt/luna_ace/ace_device.conf .

3． Specify the URL of the LunaAceConverter service in the luna_platform_address parameter.

To get the URL of the service, you need to go to the created LunaAceConverter service in Access and copy the full path from the browser search bar:

http://<ip_address>:9092/service/<UUID>

4． Change to the directory: cd /opt/luna_ace/services/ace_device

5． Restart the device: restart

LunaCars#

Software and hardware integration required for communication between LUNA CARS and barriers (boom barriers, sliding gates, bollards, and others) for vehicle access control.

Supported LUNA CARS modules:

• LUNA CARS API: v.4.0.15;
• LUNA CARS Stream: v.3.0.20;
• LUNA CARS Analytics: v.4.0.8;

Access links to LUNA CARS Analytics backend.

Events in the queue are of type CarDetectionEvent.

LunaCars settings#

The following settings are used when creating a new service (Table 22):

Table 22. Setting up the LunaCars service

LunaStreams#

A service for working with LunaStreams.

LUNA Streams is a service of VisionLabs FaceStream.

The service is designed to:

• receive a list of stream names from LUNA Stream for subsequent transmission to the ACS;
• generating a detection event based on a frame from LUNA Stream for subsequent sending for matching to Luna, CbsMts or CbsAlpha.

Supported version is:

• FaceStream 5.1.6 or newer;
• LunaStreams 0.2.1 or newer.

Configuring LunaStreams settings#

Service settings and possible values (Table 23):

Table 23. Setting up the LunaStreams service

Parsec#

This service is designed to interact with the Parsec ACS to ensure the passage of recognized persons through a turnstile/door with a magnetic lock.

Parsec functionality#

Main features:

• receiving information about access points;
• receiving regular updates from the ACS software database;
• sending requests to add/edit/delete data in the local person storage;
• receiving identification events;
• sending a request to the ACS software about identification events;
• integration with MTS KBS and LP 5;
• logging events about an attempt by an unidentified employee to pass through the turnstile.

Parsec settings#

The following settings are used when creating a new service (Table 24):

Table 24. Setting up the Parsec service

PercoWeb#

The service is designed for interaction with the [PERCo-Web] ACS (../perco.md#percoweb-scud).

PercoWeb functionality#

Main features:

• adding devices that LP5 will work with;
• receiving regular updates from the ACS software database;
• sending requests to add/change data to LP5;
• receiving identification events;
• sending requests to the ACS software about identification events;
• logging events about an attempt by an unidentified employee to pass through the turnstile.

PercoWeb settings#

The following settings are used when creating a new service (Table 25):

Table 25. Setting up the PercoWeb service

PersonStorageActualization#

The service periodically updates the data in the person storage (PersonStorage). It removes a person from the person storage if they were not found in the biometric system.

PersonStorage stores information about employees in the ACS and their descriptor_id from the biometric system.

PersonStorageActualization Settings#

Service settings and possible values (Table 26):

Table 26. PersonStorageActualization service configuration

Rusguard#

The service is designed to interact with ACS RusGuard.

Rusguard functionality#

Main functions:

• getting regular updates from the database BY ACS;
• sending requests to add/change data in the local person storage;
• receiving identification events;
• sending a request to the ACS software about identification events;
• logging events about an unidentified employee's attempt to pass through the turnstile;
• integration with CBS is possible.

Configuring settings for connecting to Rusguard#

Service settings and possible values (Table 27):

Table 27. Configuring the Rusguard service

Salto#

The service is designed to interact with the SALTO ACS.

Configuring settings for connecting to Salto#

When creating a new service, the following settings are used (Table 28):

Table 28. Configuring the Salto service

Sigur#

The service is designed to interact with the Sigur ACS.

Sigur functions#

Main functions:

• adding devices with which LP5 and LUNA CARS will work;
• receiving regular updates from the ACS software database;
• sending requests to add/change data in LP5;
• receiving identification events;
• integration with CBS: MTS, VTB, Ak Bars;
• sending a request to the ACS software about identification events.
• logging events about an attempt by an unidentified employee to pass through the turnstile.

Setting parameters for connecting to Sigur ACS#

To add a service, you need to create it with the following settings (Table 29):

Table 29. Setting up the Sigur service

SigurThroughDatabase#

The service provides integration with the Sigur ACS through a direct connection to its database.

Access synchronizes employee data from the Sigur database, taking into account only those users who have an access card.

Upon successful identification of an employee in the Luna biometric system, Access sends his card number to the GateController or PusrController intermediate controllers physically connected to the Sigur ACS. These controllers transmit commands to open/close the passage.

Integration is carried out directly with the Sigur database, without using the API

Sigur does not initiate a connection with Access — data is transmitted only in one direction (from Access to Sigur via controllers)

Sigurthdatabase functionality

Main functions:

• receiving regular updates from the database on ACS;
• sending requests for adding/changing data to the SRL;
• receiving identification events;
• sending a request to the ACS software about identification events;
• logging of events about an attempt by an unidentified employee to pass through the turnstile.

LP5 Integration Options#

Each LP5 integration (Table 30) uses the Luna service.

Table 30. LP5 Integration Options

Configure settings for connecting to Sigurthdatabase#

When creating a new service, the following settings are used (Table 31):

Table 31. Configuring the Sigurthdatabase service

Strazh#

The service is designed to interact with the [STRAZH] ACS (../strazh.md#strazh-scud).

• Supports integration with CBS MTS.

Strazh settings#

To add a service, you must create it with the following settings (Table 32):

Table 32. Configuring the Strazh service

Ubs#

The service receives and processes messages from Kafka in the Moscow regional segment of the EBS, with the final processing result being the creation of an identification event.

Ubs settings#

Service settings and possible values (Table 33):

Table 33. Ubs service setup

APACS ACS#

Software integrations of the APACS ACS with biometric systems are implemented to ensure the passage of recognized persons through a turnstile/door with a magnetic lock.

• The supported version of the APACS ACS is 8.3.1.0.

Connection of AAM LAN 8W and AAN controllers is supported.

The ability to run multiple instances of Luna Access integrated with a single APACS ACS is supported.

Supported integration options for APACS ACS#

The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.

Transfer of user data from the ACS to LP5 occurs using two mechanisms:

• replication - the mechanism for the initial transfer of user data;
• synchronization - the mechanism for periodic transfer of user data when the composition/data of users changes.

For the synchronization/replication settings, see the service settings.

Each integration with LP5 (Table 34) uses the Luna service.

If the terminal does not have data output facilities (e.g., a screen), the SendToDevice pipeline is not required.

Table 34. LP5 integration options

Each integration with CBS (Table 35) uses the CBS service.

Table 35. CBS integration options

Standard integration using Apacs#

Integration 1f (Figure 48) and (Table 36).

Table 36. Integration description

Integration 2f (Figure 49) and (Table 37).

Table 37. Integration description

Guest pass with two-factor authentication#

If you need to pass a guest with active two-factor authentication and no possibility to get a guest photo, you need to perform the following steps:

1． Add a person to the ACS without a photo with full name and card number.

2． Enable the use_cards_without_face option in the Apacs2FA pipeline settings.

Creating a user in RabbitMQ#

To create a user in RabbitMQ with read- and write-only rights to a specific queue, follow these steps:

Available on the server where Apacs is deployed.

1． Open the Windows command prompt.

2． Navigate to the directory of executable files for RabbitMQ:

cd "c:\Program Files\RabbitMQ Server\rabbitmq_server-*.*.*\sbin"

Substitute the value of the RabbitMQ Server version instead of the * character.

3． Add the user to RabbitMQ:

rabbitmqctl add_user <login> <password>

Substitute your own values instead of <login> and <password>. For more information, see the official website.

4． Add rights to the user:

rabbitmqctl set_permissions -p / <login> "^apc.webapi.vl-access-2" "^apc.webapi.vl-access-2" "^apc.webapi.vl-access-2" 

Substitute your own value instead of <login>. For more information, see the official website.

These rights make it possible to create an exchange for the Apacs ACS in order to queue events about user changes. These rights also allow you to read events from this queue for further synchronization of users for Access.

Methods of interaction with Apacs#

Beginning of endpoint for all requests (Table 38): /v1/webapi/v3.

Table 38. APACS methods

Apacs interaction process diagrams#

Connecting the Apacs service#

Sequence diagram (Figure 50).

1． The user added the Apacs service to Access.

2． Access sends an authorization request to the ACS.

3． The ACS returns a token for authorization. The token has a lifetime, after which Access re-performs authorization.

4． Access sends a request to obtain information about the ACS.

5． The ACS returns information. Access uses only the ACS version to check compatibility and user information in the UI.

6． Access sends a request to create a queue in rabbitMQ to view employee events.

7． The ACS returns the queue ID.

8． Access creates a request to replicate employees from the ACS.

9． ACS returns query_id.

10． Access sends a request to obtain results for the replication request.

11． ACS returns person_id, full name, status, photo, date and time of the last change.

12． Access sends a request with employee photos to the BS to extract descriptor_id (face_id).

13． BS returns descriptor_id.

14． Access saves information on each employee in local storage.

Processing Apacs events with 1 factor#

Sequence diagram (Figure 51).

1． Employee at the biometric terminal at the checkpoint.

2． The terminal sends the best shot of the employee to Access.

3． Access sends a photo of the employee to the Biometric System.

4． The BS compares the photo from the terminal and the one saved in the database.

5． The BS returns the matching result to Access.

6． Access compares the face card number and the card number received from the employee.

7． Access sends the card number to the ACS.

8． The ACS makes a decision to allow the person through.

Processing Apacs events with 2 factors#

Sequence diagram (Figure 52).

1． Employee at the biometric terminal at the checkpoint.

2． The terminal sends the best photo of the employee to Access.

3． Access sends the employee's photo to the Biometric System.

4． The BS compares the photo from the terminal and the one saved in the database.

5． The BS returns the matching result to Access.

6． Employee applies the card (the card use subprocess does not depend on photo processing, but, as a rule, the photo arrives first).

7． Access compares the face card number and the card number received from the employee.

8． Access sends the card number to the ACS.

9． The ACS makes a decision on whether to allow the person through.

Apacs FAQ#

1． What is Facility_code?

Card numbers in Apacs have an offset that includes the organization number.

Access automatically cuts off the facility code when comparing card numbers (for example, an employee has a card 070.56458, in the ACS it is entered as 156458, where 1 is the offset).

2． The person has not replicated, what should I do?

If an employee replication error appears in the log during replication or the employee is not in the LP5 list (can be seen via LUNA CLEMENTINE), although he is in the ACS, then you need to go to the employee data > Accesses in the ACS, disable Activity and save the changes. Then enable Activity and save the changes.

Bastion ACS#

The ACS synchronizes employees with the local person storage and listens to events, based on which it decides whether or not to open the turnstile. These events are generated in Access by the CreateBastionEvent pipeline.

• Supports Bastion ACS version: 2.1.11.2337, 2.1.13.2347, 2025.1, 0.23.3-17064.

For integration with Bastion 2, it is necessary to use pipelines that invoke text display on the terminal (it is recommended to use SendToDevice, or LunaEventListener when working with Luna).

In integration with Bastion 3, separate pipelines for text rendering are not required - this function is performed by CreateBastionEvent.

When connecting devices, it is necessary to specify the names of access points automatically generated by the service based on the access control system access points. They are specified in the Info service. They are generated in the format 'access point name - identifier'. For example: 'turnstile_exit - 907efa78-cb2f-4f46-b374-785c7f9901a5'.

The received access point names must be specified in:

• When using internal Access devices (HikvisionTerminal, Panda ...), specify in the "name" field
• When using LunaStream, specify in the "source" field

Supported integration options for Bastion ACS#

The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.

Transfer of user data from the ACS to LP5 occurs using two mechanisms:

• replication - the mechanism for the initial transfer of user data;
• synchronization - the mechanism for periodic transfer of user data when the composition/data of users changes.

For the synchronization/replication settings, see the service settings.

Each integration with LP5 (Table 39) uses the Luna service.

If the terminal does not have data output facilities (e.g., a screen), the SendToDevice pipeline is not required.

Table 39. LP5 integration options

Each integration with CBS (Table 40) uses the CBS service.

Table 40. CBS integration options

Standard integration using Bastion#

Bastion ACS software integrations with biometric systems are implemented to ensure the passage of recognized persons through a turnstile/door with a magnetic lock.

Bastion integration scheme for the passage of recognized faces through a turnstile/door with a magnetic lock. Standard Access components (Figure 53) and (Table 41) are used when integrating with Bastion.

Table 41. Integration Description

Setting up the Bastion 3 ACS software#

1． Open the Bastion-3 ACS software — Control Panel.

2． Go to the Drivers → Face Driver → "Face" Driver Configurator → General Settings section (Figure 54)

3． Set the ONVIF port, login, and password.

4． Go to the "External System Servers" section and add a new server by clicking "+".

5． In the new server settings, enter the Access address in the "host:port" format in the "person profile management service" and "event service" address fields, set the login and password for both services (Figure 55)

6． Go to the "Physical access points" section and add a new access point by clicking "+".

7． Select the Door N R{N} access point.

8． In the "Description" field, enter the name of the camera that works with this access point.

The access point description must match the device name in Access.

9． Select the "Access in identification mode" operating mode.

When changing the access point mode in the ACS, you must restart the Bastion service in Access (Figure 56)

10． Save the changes by clicking the floppy disk icon.

11． Configure pass management: Bastion 3 → Access Bureau.

12． Create a new pass request. Go to Requests → Click "+" on the toolbar (Figure 57).

13． Fill in the required fields and click OK (Figure 58)

14． Issue passes. Go to Requests → Select the target request → Click "Issue pass" on the toolbar (Figure 59)

15． Check "Issue a new access card" → Generate a random code → Issue (Figure 60)

Issued passes are displayed on the "Issue" tab.

16． Editing a pass. Go to the Issued tab → Required pass → Pass properties.

Setting up a two-factor Bastion access point#

1． Open the Bastion-3 ACS software — Control Panel.

2． Go to the Drivers → Face Driver → "Face" Driver Configurator → Physical Passage Points section and select/add a passage point.

3． In the "Description" field, enter the name of the camera that works with this passage point.

The passage point description must match the device name in Access.

4． Select the "Access in two-factor authentication mode" operating mode.

When changing the mode at the passage point in the ACS, you must restart the Bastion service in Access.

5． Save the changes by clicking the floppy disk icon (Figure 61)

6． Open the Control Panel and go to the Drivers → Personnel settings profiles section (Figure 62)

7． Select a profile → Permissions and enable the "Access with confirmation" function.

8． Save the changes by clicking the floppy disk icon (Figure 63)

9． In the Access UI, go to the "Services" tab and click the Bastion component restart button. In the Bastion component info, check the "enabled_2fa" setting of the access point that you edited in the previous step.

Methods of interaction with Bastion#

Access acts as a server and a client (Table 42).

ONVIF methods are sent to Access at the POST /vl-access/webhook/service/onvif/{component_id} endpoint.

Table 42. Bastion methods

Bastion Interaction Process Diagrams#

Connecting the Bastion service and replicating employees#

Sequence diagram (Figure 64).

Connecting the service

1． The user added the Bastion service to Access.

2． Access sends a request to the ACS to obtain access points. The obtained access points are displayed in the info field of the service properties. The request is used to check the availability of the ACS.

3． The ACS returns access points.

4． The ACS sends a request to Access to obtain a list of Access services that support the ONVIF protocol.

5． Access returns the component_id of the ONVIF services.

Employee replication

6． ACS sends a request to Access to get a list of all persons.

7． Access returns a list of persons.

8． The ACS sends a POST request to Access at /vl-access/webhook/service/onvif/{component_id} CreateCredential (or DeleteCredential, ModifyCredential) to manage employees in the Access storage.

9． Access sends a request with employee photos to the BS to extract descriptor_id (face_id).

10． BS returns descriptor_id.

11． Access saves information on each employee to local storage.

Events with 1 factor

12． ACS sends a request to Access to open a subscription to receive events (the best shots of a person at the terminal).

13． The ACS sends a POST /vl-access/webhook/service/onvif/{component_id} PullMessages request every 10 seconds to wait for a pass event.

14． Access returns the pass event to the ACS.

15． The ACS makes a decision to open the terminal.

Processing Bastion events with 2 factors#

Sequence diagram (Figure 65).

1． Access sends a PullMessages request to the ACS every 10 seconds to wait for a passage event.

2． Access receives the best photo of the employee at the terminal.

3． Access sends a photo of the employee to the Biometric System.

4． The BS compares the photos from the terminal and the one saved in the database.

5． The BS returns a decision to grant access to Access.

6． Access returns a passage event to the ACS.

7． The ACS decides to open the terminal.

Bolid ACS#

Hardware and software integration required for communication between the LP5/CBS and the Bolid ACS software to ensure control of the connected device (C-2000 series devices or other devices compatible with the Bolid software).

Supports Bolid version 1.20.3, Orion Pro integration module version 1.4.

Information interaction is provided through the Orion Pro automated workplace software.

The Orion PRO licensed integration module must be installed and launched.

The integration module is a SOAP web service accessed via the HTTP/HTTPS protocols. The description of the web service complies with the WSDL version 2.0 specification.

The service runs under Windows 7/8/8.1/10 (32 bit or 64 bit).

Supported integration options for Bolid ACS#

The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.

User data is transferred from ACS to LP5 using two mechanisms:

• replication - the mechanism for the initial transfer of user data;
• synchronization - the mechanism for periodic transfer of user data when the composition/data of users changes.

For the synchronization/replication settings, see the service settings.

Each integration with LP5 (Table 43) uses the Luna service.

If the terminal does not have data output means (for example, a screen), the SendToDevice pipeline is not required.

Table 43. LP5 integration options

Each integration with CBS (Table 44) uses the CBS service.

Table 44. CBS integration options

Standard integration using Bolid#

When integrating with Bolid, standard Access components (Figure 66) and (Table 45) are used.

When using 1f integration (without a card) components, transferring the card number to Access is not required.

Table 45. Integration description

Setting Bolid ACS#

Preparatory actions with Orion Pro software#

To launch and configure Bolid, you need to perform preparatory steps with the Orion Pro software:

1． Launch the Orion Pro Central Server application.

2． Launch the Orion Shell application.

3． Launch the ADB module on the Orion Shell panel (Figure 67):

4． Launch the Orion Pro Integration Module.

5． Launch the Operational Tasks (OT) on the Orion Shell panel if they do not start automatically.

Adding an employee in Orion Pro#

1． Add a new employee. Fill in the required fields (Figure 68) according to the rules for creating employees at the facility:

2． Go to the Employees section

3． Click the "add" button

4． Fill in the required employee fields

Select the "Administrator" status, or another department with employees who have full access to the system.

5． Add the "Maximum" access level to the new user and set a password (Figure 69).

6． Go to the Access section;

7． Click Add;

8． Select the desired employee, enter the password

9． Select the Maximum access level

Adding devices to Orion Pro#

1． Add a new section (Figure 70):

2． Select the "System structure" tab;

3． Select "sections";

4． Select all "Sections";

5． Add a new section with standard parameters and name it.

6． Link devices to the newly created section (Figure 71):

7． Select a section.

8． Click the "Add" button.

9． Go to the list of devices and select the required ones (Figure 72):

10． Select it and click the [>>] button to move it to the active field;

11． Confirm the changes by clicking [OK];

12． Click the "Save" button.

13． Edit the orion.ini file in the folder with the installed Orion Pro application (located by default: C:\BOLID\ARM_ORION_PRO1_20_3), adding the following parameters (if they are missing):

[Checkerdb]
Remarks=1
timechecker=5
Logon=1
RemoteCmd=1
CmdOn=1
[ChangeDB]
on=1

14． Restart all Orion Pro applications.

Configuring the “ORION PRO INTEGRATION MODULE” application#

To configure the “ORION PRO INTEGRATION MODULE” application, follow these steps:

1． Download the official distribution kit of the “ORION PRO INTEGRATION MODULE” application (link).

2． Run the installation. After the installation is complete, launch the module, check the database connection settings. If everything works correctly, close the module.

3． Install the module to run as a service. To do this, run the command in the terminal as administrator in the folder with the installed module (for example: C:\BOLID\IntegrServ):

IntegrServ.exe /INSTALL

4． In the system control panel, find the installed service and run it by clicking the right mouse button and selecting “Start” (Figure 73).

Methods of interaction with Bolid#

An API is used тo exchange data with the ACS (Table 46).

Table 46. Bolid methods

Bolid Interaction Process Diagrams#

Bolid Service Connection#

Sequence diagram (Figure 74).

1． The user added the Bolid service to Access.

2． Access sends a request to obtain information about the ACS.

3． The ACS returns information. Access checks the availability of the ACS and uses the ACS version to check compatibility and user information in the UI.

4． Access sends a request for the correctness of the login/password pair from the account in the ACS.

5． The ACS returns the account activity status. If the record is active, then work continues.

6． Access sends an authorization request to the ACS.

7． The ACS returns a token for authorization. The token has a lifetime, after which Access re-performs authorization.

8． Access sends a request to obtain information about employees to replicate data to the local storage.

9． The ACS returns person_id, full name, status, photo, date and time of the last update.

10． Access sends a request with employee photos to the BS to retrieve descriptor_id (face_id).

11． The BS returns descriptor_id.

12． Access saves information on each employee in local storage.

Event processing with 1 factor#

Sequence diagram (Figure 75).

1． Employee at the biometric terminal at the checkpoint.

2． The terminal sends the best shot of the employee to Access.

3． Access sends a photo of the employee to the Biometric System (BS).

4． BS compares the photo from the terminal and the one saved in the database.

5． BS returns descriptor_id to Access.

6． Access looks for the employee's card number by correlating descriptor_id and person_id.

7． Access sends the card number to GateController.

8． GateController sends the card number to ACS.

9． ACS makes a decision to allow the employee through.

Event processing with 2 factors#

Sequence diagram (Figure 76).

1． Employee at the biometric terminal at the checkpoint.

2． The terminal sends the best shot of the employee to Access.

3． Access sends the employee's photo to the Biometric System.

4． The BS compares the photo from the terminal and the one saved in the database.

5． The BS returns the descriptor_id to Access.

6． Access looks for the employee's card number by correlating the descriptor_id and person_id.

7． The employee applies the card (the card use subprocess does not depend on photo processing, but, as a rule, the photo arrives first).

8． The ACS sends the card number to Access.

9． Access compares the card numbers received in steps 6 and 8.

10． Access sends the card number to the GateController.

11． GateController sends the card number to the ACS.

12． The ACS makes a decision to open.

Bolid FAQ#

1． Why can't I add an employee photo larger than 100 kb?

• In Orion Pro, the maximum permissible photo size may be reset to 100 kb. You need to go to ADB Orion Pro Settings > Settings > Employees > "Maximum size of employee photos, kb" and set it to 10240 kb (10 MB) or more.

Gate ACS#

The integration module (sync.exe), launched in the Gate Server directory, detects changes in the database and sends changes to the ip:port specified in the .env settings file. VL Access accepts and processes these requests, and makes appropriate changes to the Luna list.

Supported versions: Gate Terminal 1.22.95, Gate Server 1.22.95

Supported integration options for Gate ACS#

The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.

Transfer of user data from the ACS to LP5 occurs using two mechanisms:

• replication - the mechanism for the initial transfer of user data;
• synchronization - the mechanism for periodic transfer of user data when the composition/data of users changes.

For the synchronization/replication settings, see the service settings.

Each integration with LP5 (Table 47) uses the Luna service.

If the terminal does not have data output facilities (e.g., a screen), the SendToDevice pipeline is not required.

Table 47. LP5 integration options

Parsec ACS#

Supports ParsecNET 3 ACS version: 3.11.629 39.

The service allows you to process requests from access control systems, such as:

• transfer the list of employees to the local person storage,
• adding/editing/deleting employees in the local person storage,
• receiving detection events from devices.

The service executes the following requests to the ACS:

• sending url address of ONVIF services;
• getting access point IDs.

When starting the service, access point identifiers are first requested and their names are generated.

The ACS queries Access for detections and generates a response containing the employee ID and the access point ID.

As soon as a valid face detection occurs, the service returns a response to the ACS.

To integrate with Parsec, you must specify the names of access points automatically generated by the service in the device settings. They are generated in the format 'access point name - identifier'. For example: 'Turnstile exit - 907EFA78-CB2F-4F46-b374-785c7f9901a5'

The resulting access point names must be inserted into the appropriate fields:

• When using internal Access devices (HikvisionTerminal, Panda ...), indicate in the "name" field.
• When using LunaStream, indicate in the "source" field.

Supported integration options for Parsec ACS#

The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.

Transfer of user data from the ACS to LP5 occurs using two mechanisms:

• replication - the mechanism for the initial transfer of user data;
• synchronization - the mechanism for periodic transfer of user data when the composition/data of users changes.

For the synchronization/replication settings, see the service settings.

Each integration with LP5 (Table 48) uses the Luna service.

If the terminal does not have data output facilities (e.g., a screen), the SendToDevice pipeline is not required.

Table 48. LP5 integration options

Each integration with CBS (Table 49) uses the CBS service.

Table 49. CBS integration options

Standard integration using Parsec#

When integrating with Parsec, standard Access components (Figure 77) and (Table 50) are used.

Table 50. Integration Description

Configuring Access and Parsec ACS integration#

To launch and configure the Parsec ACS software, install Parsec.NET and run the Administration program and check the settings (Figure 78):

1． Make sure that the ""Advanced Mode"" is running (File→Advanced Mode).

2． Go to the “Equipment editor” section and make sure that the controllers are connected .

3． For each required controller, set the following settings in the “Access Modes” tab (Figure 79).

4． Go to the “System settings editor” section, then open the “Face Recognition (ONVIF)” tab (Figure 80).

5． In the “Face recognition (ONVIF)” window, click the “Change” button and make sure that the “Use FRS” item is enabled, and the “FRS type” is set to “ONVIF face recognition”.

6． In the “IP Address” and “Port” fields, enter the Access server data.

The IP address of all components must point to the Access server.

7． Click the “Check connection” button only after configuring Access, this will require the “Integration key”.

8． After clicking on the “Check connection” button, the fields in the “Face recognition system services” block will be filled in automatically.

9． Click the “Save” button.

10． Replicate employees to the Luna list by clicking the “Transfer employees and visitors” button. Before, make sure that all staff members are correctly added in the "Staff Editor" section, see «Adding staff to Parsec ACS»

Example of displaying staff member unloaded from Parsec ACS to LUNA PLATFORM list (Figure 81).

Configuring access groups in Parsec ACS#

1． Click the «Access group editor» section.

2． Add a new access group.

3． Add an access territory where the access points are included (Figure 82).

4． Click the Save button.

Adding staff to Parsec ACS#

Adding staff members to Parsec ACS is necessary for their subsequent upload to LUNA PLATFORM (Figure 83).

1． Click the «Staff Editor» section.

2． Click the button of adding a new staff member.

3． Fill in the «Last Name» and «First Name» fields.

4． Add a photo of the staff member.

5． Fill in the «Card code» field. The «PIN» field will be filled in automatically.

If card access is not provided at the facility or the staff member does not have a card, enter any value in the «Card code» field.

6． Select the staff member's access group.

7． Click the Save button.

If you add staff members correctly, all new or changed data will be added to the LUNA PLATFORM database automatically.

Methods of interaction with Parsec#

Access acts as a server and a client (Table 51).

Sending ONVIF methods to Access occurs at the POST endpoint /vl-access/webhook/service/onvif/{component_id}.

Table 51. Parsec methods

Parsec interaction process diagrams#

Connecting the Parsec service#

Sequence diagram (Figure 84).

1． The user added the Parsec service to Access.

2． Access sends a request to the ACS to obtain access points. The obtained access points are displayed in the info field of the service properties. The request is used to check the availability of the ACS.

3． The ACS returns the access points.

4． The ACS sends a request to Access to obtain a list of Access services that support the ONVIF protocol.

5． Access returns the component_id of the ONVIF services.

6． The ACS sends a POST /vl-access/webhook/service/onvif/{component_id} CreateCredential request to Access to transfer employees to the Access repository.

7． Access sends a request with employee photos to the BS to retrieve descriptor_id (face_id).

8． The BS returns descriptor_id.

9． Access saves information on each employee to local storage.

10． The ACS sends a request to Access to open a subscription for receiving events (best frames of a person at the terminal).

Parsec event processing with 2 factors#

Sequence diagram (Figure 85).

1． ACS sends a POST /vl-access/webhook/service/onvif/{component_id} PullMessages request every 10 seconds to wait for a passage event.

2． Access receives the best photo of the employee at the terminal.

3． Access sends a photo of the employee to the Biometric System.

4． BS compares the photos from the terminal and the one saved in the database.

5． BS returns to Access a decision on granting access.

6． Access returns a passage event to ACS.

7． ACS makes a decision on opening the terminal.

PERCo-Web ACS#

Software integration of the PERCo-Web ACS software with LP5 is implemented to ensure the passage of recognized persons through a turnstile/door with a magnetic lock.

Supports PERCo-Web system version 2.0, build number 4.30.

Performs user data replication from the PERCo ACS to the specified Luna list and generates PercoController controllers from the received list of devices for execution of entry or exit requests.

Supported integration options for PERCo-Web ACS#

The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.

Transfer of user data from the ACS to LP5 occurs using two mechanisms:

• replication - the mechanism for the initial transfer of user data;
• synchronization - the mechanism for periodic transfer of user data when the composition/data of users changes.

For the synchronization/replication settings, see the service settings.

Each integration with LP5 (Table 52) uses the Luna service.

If the terminal does not have data output facilities (e.g., a screen), the SendToDevice pipeline is not required.

Table 52. LP5 integration options

Standard integration using PERCo-Web#

Only 1-factor integration is supported (Figure 86) and (Table 53).

Table 53. Integration description

Methods of interaction with PERCo-Web#

Start of endpoint for all requests (Table 54): /api.

Table 54. PERCo-Web methods

Diagrams of interaction processes with PERCo-Web#

Connecting the PERCo-Web service#

Sequence diagram (Figure 87).

1． The user added the PERCo-Web service to Access.

2． Access sends a request for authorization to the ACS.

3． The ACS returns a token for authorization. The token has a lifetime, after which Access re-performs authorization.

4． Access sends a GET /system/language/ request to determine whether the service is active.

5． The ACS returns a response.

6． Access sends a request to obtain a list of active controllers.

7． The ACS returns an array of device_id.

8． Access sends a request to obtain information about the controller, for each received device_id.

9． ACS returns controller data.

10． Access creates PercoController based on the number of received device_ids.

11． Access sends a request to replicate employees from ACS.

12． ACS returns employee data.

13． Access sends a request to receive photos of employees who are active and have photos.

14． ACS returns employee photos.

15． Access sends a request with employee photos to the BS to retrieve descriptor_id (face_id).

16． BS returns descriptor_id.

17． Access saves employee data in storage.

18． Access sends a request every 10 seconds to receive events about employee changes to perform synchronization.

19． ACS returns events.

PERCo-Web event processing with 1 factor#

Sequence diagram (Figure 88).

1． Employee at the biometric terminal at the checkpoint.

2． The terminal sends the best shot of the employee to Access.

3． Access sends the employee's photo to the Biometric System.

4． The BS compares the photo from the terminal and the one saved in the database.

5． The BS returns the matching result to Access.

6． Access searches for the employee's number based on the received descriptor_id.

7． Access sends the employee's number to the ACS.

8． The ACS makes a decision to allow the person through.

Rusguard ACS#

Software integrations of Rusguard ACS with biometric systems are implemented to ensure the passage of recognized persons through the turnstile.

The service replicates employees from the ACS to its database by requesting the descriptor ID in the CBS based on the employee's photo. To update the data, the replication session is restarted 5 seconds after completion.

• Supports versions: System - 3.3.1, Database - 3.3.1

Supported integration options for Rusguard ACS#

The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.

Transfer of user data from ACS to LP5 occurs using replication - the mechanism for the initial transfer of user data.

For the replication settings, see the service settings.

Each integration with LP5 (Table 55) uses the Luna service.

If the terminal does not have data output facilities (e.g., a screen), the SendToDevice pipeline is not required.

Table 55. LP5 integration options

Each integration with CBS (Table 56) uses the CBS service.

Table 56. CBS integration options

Standard integration using Rusguard#

When integrating with Rusguard, standard Access components (Figure 89) and (Table 57) are used.

Table 57. Integration description

Methods of interaction with Rusguard#

An API is used тo exchange data with the ACS (Table 58).

Table 58. Rusguard methods

Diagrams of interaction processes with RusGuard#

Diagram of interaction between RusGuard ACS and Access#

Sequence diagram (Figure 90).

1． The user added the Rusguard service to Access.

2． Access sends a GET /GetCardTypes request to retrieve card types in the ACS, to check the connection.

3． The ACS returns an array of card_types.

4． Access sends a GET /GetAcsEmployeePhotoInfos request to obtain information about the availability of employee photos and the dates of their last changes in the ACS.

5． The ACS returns an array of photos.

6． Access sends a GET /GetAcsEmployeeGroups request to obtain a list of employee groups in the ACS.

7． The ACS returns an array with group data (ID and group name).

8． Access sends a GET /GetAcsEmployeesInGroup request to get employees from a group, for each group from the previous request.

9． ACS returns an array with data for each employee.

10． Access checks if the employee photo is out of date

11． Access sends a GET /GetPhotoEmployee?PersonGuidId=employee_id&photoNumber=photo_number request to get a photo for each employee from the previous request, where:

• employee_id - employee identifier
• photo_number - photo number in ACS

12． ACS returns a response with an employee photo in base64 format for each employee.

13． Access saves employee data to the storage.

Diagram of interaction between Access and the biometric system#

Sequence diagram (Figure 91).

1． An employee at the biometric terminal at the checkpoint.

2． The terminal sends the best shot of the employee to Access.

3． Access sends a photo of the employee to the Biometric System.

4． The BS compares the photo from the terminal and the one stored in the database.

5． The BS returns to Access a decision on granting access.

6． Access determines the employee's access card number from the descriptor received from the BS and sends a signal to the controller to open the access point, specifying exactly this card number. The ACS receives the passage event.

SALTO ACS#

The ACS synchronizes employees with the list in Luna and listens to events, based on which it decides whether or not to open the turnstile. These events are generated in Access by the SendToSalto pipeline.

• Supports Salto ACS version: 6.6.3.0.

Replicates user data from the Salto database to the specified Luna list and generates SaltoController controllers from the resulting list of access points for subsequent execution of access requests.

For the configuration of the Salto ACS, see the official documentation.

Supported integration options for SALTO ACS#

The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.

User data is transferred from the ACS to LP5 using two mechanisms:

• replication - the mechanism for the initial transfer of user data;
• synchronization - the mechanism for periodic transfer of user data when the composition/data of users changes.

Each integration with LP5 (Table 59) uses the Luna service.

Table 59. LP5 integration options

Standard integration using Salto#

Salto integration (Figure 92) and (Table 60).

Table 60. Integration description

SALTO ACS Access Levels#

SALTO ACS integrated with LUNA Access has a flexible access level system.

Access levels can be assigned to both doors and employees. Each employee and each door can have a list of access level identifiers.

Information storage:

• Door access levels are stored in the info field of the corresponding controllers in LUNA Access.

• Employee access levels are stored in the local person storage.

Access check:

When attempting to open a door, LUNA Access compares the employee and door access levels. The door will only open if the employee has at least one access level that matches one of the levels assigned to the door.

Integration features:

The request to open the door is sent to SALTO ACS in an anonymous form. The ACS passage events do not display who exactly passed through using biometrics - the event is recorded as the opening of the door by the ACS operator.

Methods for interacting with Salto#

Start of endpoint for all requests (Table 61), except authorization: /rpc

Table 61. Salto methods

SALTO interaction process diagram#

Sequence diagram (Figure 93).

1． The user added the Salto service to Access.

2． Access sends a request to obtain an authorization token to the ACS.

3． The ACS returns a token for authorization. The token has a lifetime, after which Access performs authorization again.

4． Access sends a request to obtain information about the ACS.

5． The ACS returns information. Access uses only the ACS version to check compatibility and display the version in the UI.

6． Access sends a request to obtain access points created in the ACS.

7． The ACS returns a list of access points.

8． Access creates SaltoController controllers according to the received IDs.

9． Access sends a request to obtain a list of employees in the ACS.

10． The ACS returns a list of employees.

11． Access saves information on each employee to the local storage.

12． Access sends a request every 10 seconds to receive events about employee changes to perform synchronization.

13． ACS returns events.

14． Access adds/updates information on each employee to the local storage.

Sigur ACS#

The service is designed to interact with the Sigur ACS. The ACS synchronizes employees with the list in the Biometric System and listens to events, based on which it decides whether to open or not to open the turnstile. These events are generated in the VL Access pipeline SendToSigur. The protocol used is HTTP.

• Supports the Sigur ACS version: 1.6.3.18.s.

Supported integration options for Sigur ACS#

Software integrations with Sigur ACS software are implemented for interaction:

• with LP5/CBS for passage of recognized persons through a turnstile/door with a magnetic lock.
• with LUNA CARS for ensuring access control of vehicles when passing through barriers.

The face recognition device generates an event, Access transmits the event to LP5, LP5 processes the event and returns the result to Access for further processing.

User data is transferred from ACS to LP5 using two mechanisms:

• replication - the mechanism for the initial transfer of user data;
• synchronization - the mechanism for periodic transfer of user data when the composition/data of users changes.

For synchronization/replication settings, see the service settings.

If the terminal has no means of outputting data (such as a screen), the SendToDevice pipeline is not required.

LP5 Integration Options#

Each LP5 integration (Table 62) uses the Luna service.

Table 62. LP5 Integration Options

Integration options with KBS#

Each integration with KBS (Table 63) uses the KBS service.

Table 63. Integration options with KBS

Services specified in brackets, for example [CryptoPro], are not mandatory and can be used in integrations if necessary.

Integration options with LUNA CARS#

Each integration with the vehicle access control system (Table 64) uses the LunaCars service.

TC ACS - Access control system for the vehicle territory using a barrier.

LUNA CARS transmits vehicle detection events to Access for further processing.

Cameras are connected via LUNA CARS.

Table 64. Vehicle access control system integration options

Standard integrations using Sigur#

1． Sigur integration diagram for passage of recognized persons through a turnstile/door with a magnetic lock. Standard Access components (Figure 94) and (Table 65) are used for integration with Sigur.

Table 65. Integration Description

2． Sigur integration scheme for providing access control for vehicles when passing through barriers. Standard Access components (Figure 95) and (Table 66) are used for integration with Sigur.

Table 66. Integration description

Setting up Sigur ACS software#

To launch and set up Sigur ACS software, you must do the following:

1． Make sure that you are using Sigur ACS software version 1.6.3.18.s or later:

• In the Sigur control program menu, select the menu item "Help" → "About the program".
• Compare the software version with the one indicated on the website www.sigur.com.
• If necessary, update the software to the latest version.

2． Set up interaction between the integration module and the Sigur ACS software server:

• In the Sigur control program menu, select the menu item "File" → "Settings".
• In the "Edit settings" dialog, go to the "Video surveillance" item (Figure 96).
• Add a video surveillance server (Figure 97).

• Specify an arbitrary server name.
• Server type — «Custom system».
• Click «OK»;

3． Configure the server parameters (Figure 98):

• "Server address" and "Server port (HTTP)" - used when accessing the server from the ACS via HTTP;
• "Server address" corresponds to the IP address of the machine on which Access is running;
• "Server port (HTTP)" - the port for the integration module (the default value is "9091", if the port is already in use - change);
• "Path to service" specifies the common prefix of paths on the server for all requests from the ACS. This value should be taken from the information block of the Sigur component in Access, the value of the webhook-url field (Figure 99).

• Enable the "Upload photos to servers" flag when using the Sigur service, disable when using the SigurThroughDatabase service.
• Enable the "Receive events from the server" flag.

4． Enable the face recognition function:

• In the "Edit settings" dialog, go to the "Face recognition" item.
• Check the "Enable face recognition" item (Figure 100).

Setting up access points in Sigur#

If errors occur, restart the Sigur ACS software server so that it can connect to the integration module.

To set up access points in Sigur, you must do the following:

1． In the side menu of the Sigur management program, select the "Hardware" item (Figure 101).

2． Select the required access point and set up video surveillance parameters for it (Figure 102):

• "System" - select the name of the created user system;
• "Camera" - select a camera. When you click on the drop-down list, it should display the names of all devices created in Access, this indicates that the integration is working properly and Sigur was able to connect to Access. Select the device that is used to identify the desired access point;
• Activate the flags "Allow face verification" and "Enable face identification";
• Click the "Apply" button.

After this, replication of employees from Sigur should begin. For a description of the replication algorithm, see the section [Diagram of interaction between Sigur ACS and LUNA Access] (#sigur-interaction).

Setting up access modes in the Sigur ACS software#

The ACS has two identification modes in the selected direction:

• 1f mode - based on recognition of the access object's face
• 2f mode - based on the main identification feature (card) and on the access object's face

To set up the software, follow these steps:

1． In the Sigur control program, in the "Equipment" side menu, select the required access point and go to the video surveillance settings (Figure 103):

To enable 1f mode: activate the "Enable face identification" flag.

To enable 2f mode: activate the "Allow face verification" flag.

2． Go to the "Modes" tab and, having created a new one or selected the required one from the existing ones, go to the "Special rules" tab (Figure 104):

For operation in 1-phase mode: If access in any of the directions should be provided only by the fact of face recognition, then for the parameters "Face identification at the entrance/exit" set the value "Enabled".

For operation in 2-phase mode: If access in any of the directions should be provided by the fact of presenting the employee's primary ID and the fact of recognition of his face, then for the parameters "Face verification at the entrance/exit" set one of the following values:

• Soft — let in anyway. After identification by the main feature (presenting the card), the system grants access if it is possible according to other criteria, even if the person never appears in the frame. Such access permission will be accompanied by the event "Face not recognized".
• Hard — let in only if there is a match. After identification by the main feature (presenting the card), the system checks whether the person's face was recognized in the frame during the time specified in the settings before the event, and if not, waits for the person to appear in the frame within 5 seconds. If the person still does not appear in the frame, access is not granted. The "Surveillance" tab in the software displays the event: "Access denied. Face not identified."
• Strict group - skip only if matched with a face from the department. After identification by the main feature (presenting the card), the system checks whether the person's face was recognized in the frame during the time specified in the settings before the event, and if not, waits for the person to appear in the frame within 5 seconds. The detected face is checked for compliance with any of the faces located in the same department as the identified object. If the person still does not appear in the frame, access is not granted. The "Surveillance" tab in the software displays the event: "Access denied. Face not identified."
• Soft group — skip if there is no match with the person from the department. After identification by the main attribute, the system grants access if it is possible by other criteria, even if the person of the identified person or any other subject of the same department has not appeared. Such access permission will be accompanied by the event "Person not identified".

Methods of interaction with Sigur#

An API is used тo exchange data with the ACS (Table 67).

Table 67. Sigur methods

Diagram of interaction between Sigur ACS and Access#

Access acts as a server, and Sigur acts as a client. After configuring the client, Sigur ACS independently executes all requests to Luna Access (Figure 105).

Face detection events

1． Sigur ACS initiates a GET request: /event to receive face detection events from Access, the connection always remains open. 2． Access returns events to the connection as they occur. Even if there are no events, Access sends an artificial "Keep alive" event every 5 seconds so that both sides of the connection are sure that the connection is still OK. Access returns a json event object with the fields:

• type - Event type;
• channelId - Channel ID in Access;
• persons - Array with recognition results;
• id - Person ID;
• score - Similarity level as a real number from 0 to 1.

Vehicle detection events

3． Sigur ACS initiates a GET request: /event to receive vehicle detection events from Access, the connection always remains open (Access sends new events to the ACS as they occur). 4． Access returns events to the connection as they occur. Even if there are no events, Access sends an artificial "Keep alive" event every 5 seconds so that both sides of the connection are sure that the connection is still OK. Access returns a json event object with the fields:

• type - Event type;
• channelId - Channel ID in Access;
• number - String of the recognized vehicle registration plate;
• direction - Direction of vertical movement of the car in the frame. An optional field, may be absent. If present, it can take the values ​​"up" or "down".

Getting a list of employees

5． Sigur ACS initiates a GET request: /getpersons to synchronize data with Access. The request is executed when the ACS server starts and when any synchronized data on the ACS side changes. If the request or subsequent requests fail, the ACS will try to repeat the request every 5 seconds until synchronization is completed without errors. 6． Access returns a json object with the fields:

• id - employee ID;
• photoVersion - Current "photo version" of the employee in Access, the field value is the time the photo was updated in the ACS in timestamp format (unix format);
• name - Employee name.

Employee modification

7． Sigur ACS initiates a POST request: /updateperson to add or update employee data in Access. The request body contains a json object with the following fields:

• id - employee ID in ACS, an integer from 1 to 2^31-1;
• name - employee name;
• photoVersion - employee's current "photo version" in Access, the field value is the time the photo was updated in ACS in timestamp format (unix format);
• photo - JPEG photo, encoded in base64.

8． Access searches its database for an employee with the specified id. If such an id exists, then his data must be updated to match the transferred data. If such an id does not exist, then it must be created. If successful, Access returns HTTP status 200. OK. If unsuccessful, the ACS will prematurely terminate data synchronization, i.e. will stop executing updateperson and removeperson requests, the ACS will make a new attempt in 5 seconds. 9． Sigur ACS initiates a GET request: /removeperson to delete employee data in Access. The request body contains a json object with the field:

• id - ID of the employee to be deleted.

Configuration of the passage direction

10． Access searches its database for an employee with the specified id and deletes their data. If successful, Access returns HTTP status 200. OK. If unsuccessful, the ACS will prematurely terminate data synchronization; the ACS will make a new attempt in 5 seconds. 11． The Sigur ACS initiates a GET request: /getchannels to identify channels of video surveillance devices created in Access. The request is executed when the user performs actions in the ACS interface to configure the connection of channels and passage points. 12． Access returns the json object "channels" with the fields:

• id - channel ID;
• name - Channel name.

The connection of channels and passage points occurs in the ACS user interface.

Sigur FAQ#

1． Why is the drop-down list in the bio_system_id field empty when configuring the Sigur service connection parameters?

• It is necessary to check the presence of the added biometric system service, it must be of a supported type. Supported types: Luna, CbsMts.

2． Why is the drop-down list in the luna_cars_id field empty when configuring the Sigur service connection parameters?

• It is necessary to check the presence of the added LunaCars service.

3． Why did employee synchronization not start after configuring Sigur?

• The following points must be met in order for the data to synchronize:
• Recognition is enabled in the ACS software settings;
• Recognition is enabled in the equipment. The access point settings must have a camera linked and the required mode (identification or verification) checked;
• The employee must have access to this access point;
• The employee must have an access mode in which the required identification mode is enabled;
• Any edit of any employee can be the trigger for starting employee synchronization.

STRAZH ACS#

Performs replication of user data from the ACS to the specified list of the Biometric System and generates StrazhController controllers from the received list of devices for subsequent execution of requests for entry or exit.

• Supports the ACS version: 1.2.211201.648.

The integration supports operation in 1-phase and 2-phase modes.

Supported integration options for STRAZH ACS#

The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.

Transfer of user data from the ACS to LP5 occurs using two mechanisms:

• replication - the mechanism for the initial transfer of user data;
• synchronization - the mechanism for periodic transfer of user data when the composition/data of users changes.

For the synchronization/replication settings, see the service settings.

Each integration with LP5 (Table 68) uses the Luna service.

If the terminal does not have data output facilities (e.g., a screen), the SendToDevice pipeline is not required.

Table 68. LP5 integration options

In each integration with CBS (Table 69), the CBS service is used.

Table 69. KBS integration options

Standard integration using STRAZH ACS#

When integrating with STRAZH, standard Access components (Figure 106) and (Table 70) are used.

Table 70. Integration Description

2f integration (Figure 107) and (Table 71).

Table 71. Integration description

Setting up STRAZH ACS software for two-factor authentication#

The ACS has implemented privilege levels. For 1F and 2F authorization to work, the access point privilege level must be equal to the employee's level, otherwise access will be denied.

If the employee has a higher privilege level than the access point, authorization will only occur by 1F (by card).

To configure the software, follow these steps:

1． Go to ACS Settings > Access Points > Create a new one (if not created).

2． Enter the required access point data if necessary.

This completes the process of setting up 1F authorization, follow steps 3-5 if 2F is planned.

3． Click the "Additional parameters" tab and add "Confirmation of access by an external system" with the value "Yes".

4． Add the "Maximum waiting time for confirmation of access by an external system" parameter.

5． Adjust the timeout for waiting for a response from the external system and the default decision if the system does not have time to process the request.

After this, when trying to pass through this point with a card whose privilege level is lower than the privilege level of the point, an event with type: access_confirmation and data in the form of a JSON object with the fields request and response will be sent via the SSE mechanism.

The request contains a request for access, and the response contains a preliminary decision of the ACS about the possibility of access (i.e., a decision after standard checks of the profile, schedule, etc.).

Then the ACS waits for a decision on access to be sent to it via HTTP POST to /access_confirmation indicating the UUID of the request and a decision to let in or not.

Regardless of the ACS decision in response, the external system can let in or not let in.

Methods of interaction with STRAZH#

An API is used тo exchange data with the ACS (Table 72).

Table 72. STRAZH methods

STRAZH interaction process diagrams#

Strazh service connection#

Sequence diagram (Figure 108).

1． The user added the Strazh service to Access.

2． Access sends an authorization request to the ACS.

3． The ACS returns an authorization token. The token has a lifetime, after which Access re-performs authorization.

4． Access sends a request to obtain information about the ACS.

5． The ACS returns information. Access uses only the ACS version to check compatibility and user information in the UI.

6． Access requests information about access points (controllers) connected to the ACS.

7． The ACS returns the access point IDs.

8． Access creates StrazhController controllers in accordance with the received IDs.

9． Access sends a request to obtain information about employees to replicate data to the local storage.

10． ACS returns person_id, full name and photo.

11． Access sends a request to open an SSE connection to view the list of events (changes in employees, access).

12． ACS opens an SSE connection with Access.

Modifying employees in STRAZH ACS#

Sequence diagram (Figure 109).

1． Access views the event queue in ACS via SSE connection.

2． The employee is changed in ACS (added, changed or deleted).

3． Access finds events with the CREATE, MODIFY_DATA or DELETE tags in the queue.

4． Access deletes the employee from the local storage.

5． Access requests data on the employee by his person_id.

6． ACS returns the full name and photo of the employee.

7． Access updates the employee information in the local storage.

Processing STRAZH events with 1 factor#

Sequence diagram (Figure 110).

1． Employee at the biometric terminal at the checkpoint.

2． Terminal sends the best photo of the employee to Access.

3． Access sends a photo of the employee to the Biometric System.

4． BS compares the photo from the terminal and the one saved in the database.

5． BS returns to Access a decision on granting access.

6． Access sends a signal to the controller to open the access point.

Processing STRAZH events with 2 factors#

Sequence diagram (Figure 111).

1． Employee at the biometric terminal at the checkpoint.

2． The terminal sends the best shot of the employee to Access.

3． Access sends the employee's photo to the Biometric System.

4． The BS compares the photo from the terminal and the one stored in the database.

5． The BS returns to Access a decision on granting access.

6． The employee applies the card (the card use subprocess does not depend on photo processing, but, as a rule, the photo arrives first).

7． The access point sends information to Access via SSE about the passage (access point ID, passage direction, and person_id).

8． Access aggregates information about each factor and sends a signal to the controller to open the access point.

Integrations without ACS#

The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.

Each integration (Table 73) uses the Luna service.

Table 73. Integration options without ACS

Controllers#

Controllers are required to work with controllers from different manufacturers for communication between VisionLabs systems and access control devices from other manufacturers.

All fields are required unless otherwise stated in the description.

ApacsController#

The Apacs controller is generated automatically when the Apacs service is running from the received pass points. Up to 4 readers are supported.

Setting up parameters for connecting to the Apacs controller#

Apacs controller settings and possible values (Table 74):

Table 74. Apacs Controller Settings

Gate controller#

The GateController controller is designed to work with the GateEthernetWiegand converter, which can be used to send the Wiegand format card number to the controller. To run the controller, specify IP, port, and component identifiers to the corresponding device outputs in order to understand which direction to open when receiving detections from devices.

Gate Ethernet-Wiegand converter#

A specialized Gate-Ethernet/Wiegand interface converter (version 2) is used to connect recognition servers (face, vehicle registration plate or other identification feature) to the ACS controller using a special protocol. The converter provides reception of a code message via the Ethernet network from the recognition server, decoding of the received message and issuance of an identifier code to the required Wiegand input of the ACS controller. The converter is configured using a special utility — a program running under the Windows operating system. The program sets the initial IP address of the device and other communication Parameters.

Gate controller settings#

Gate Controller settings and possible values (Table 75):

Table 75. Gate Controller Settings

LaurentController#

The Laurent2 controller is designed to control and manage access together with the Luna Cars service.

• Supported devices: Laurent2.
• Supported firmware versions: L212.

Laurent controller settings#

Controller settings and possible values (Table 76):

Table 76. Laurent Controller Settings

PercoСontroller#

The PERCo controller is generated automatically during the operation of the PERCo-Web service from the devices received at startup. To use it, you must manually enter the entry_source and exit_source values ​​for each of the created controllers.

PercooСontroller settings#

Controller settings and possible values (Table 77):

Table 77. PERCo Controller Settings

PusrController#

The controller is designed to work with the WGNetConverter converter, which can be used to send the Wiegand format card number to the controller.

• Supported devices: WG-TCP
• Supported firmware: V6005

It is important that the converter is in TCP Server mode. To do this, during the initial setup, select the appropriate Work Mode in the web interface in the Serial Port section.

Pusr controller settings#

Controller settings and possible values (Table 78):

Table 78. Settings of the Pusr Controller

Salto controller#

The Salto controller is generated automatically when the Salto service is running from the received pass points. For use and operation, after generation, it is necessary to manually enter the entry_source value for each of the created controllers.

Salto controller settings#

Controller settings and possible values (Table 79):

Table 79. Salto Controller Settings

Strazh controller#

The Strazh controller is generated automatically when the Strazh service is running from the devices received at startup. After generation, it is necessary to manually enter the source value for each of the created controllers.

Strazh controller settings#

Controller settings and possible values (Table 80):

Table 80. Strazh Controller Settings

Devices#

To perform hardware-software integration of LP5/LUNA CARS for access control, it is necessary to use devices - a terminal, cameras, etc.

All fields are required unless otherwise stated in the description.

Beward#

The biometric terminal with temperature measurement, mask detection, and built-in relay.

• Supported devices: TFR80-210T1Q / TFR80-210.
• Supported firmware versions: 1.2.13.0 / 2.1.6.0.

Beward settings#

Device settings and possible values (Table 81):

Table 81. Settings of Beware

BioSmart Quasar#

• Supported devices: BioSmart Quasar.
• Supported firmware versions: 2.3.0.46.

BioSmart Quasar settings#

Settings for creating a new device (Table 82):

Table 82. BioSmart Quasar Settings

To subscribe to events, go to “Settings” on the terminal → go to “Server Identification” → select the server type: BioSmartLite → enter the endpoint for sending data: http://server_IP/vl-access/webhook/biosmart/ → save the settings.

The device does not generate events and does not put anything in the queue. Requests to Luna are sent directly from endpoints.

Dahua#

Some models of Dahua cameras have a relay and the ability to control it programmatically.

During the implementation of the project, LP5 is integrated with this functionality, which allows to control the relay when a face from a certain list appears in the frame.

For example, it is possible to send a signal to an electronic door lock so that the door opens or does not open.

The device starts a stream connection, generates, and puts a face detection event in the queue.

Dahua settings#

Device settings and possible values (Table 83):

Table 83. Dahua Settings

DahuaThermo#

Some models of Dahua cameras have a relay and the ability to control it programmatically.

During the implementation of the project, LP5 is integrated with this functionality, which allows to control the relay when a face from a certain list appears in the frame.

For example, it is possible to send a signal to an electronic door lock so that the door opens or does not open.

• Supported system version: 2.631.0000000.31.T, build date 2020-07-06.

The device starts an HTTP stream connection to the thermal imaging camera and captures faces by sending a thermal detection event of the face to the queue.

DahuaThermo settings#

To start, you must specify the following settings (Table 84):

Table 84. DahuaThermo Settings

Fortuna315#

Generates Thermo events in the SendThermalEventToLuna queue based on the received data from devices. Includes paired devices — thermal imaging camera and camera.

Supported firmware versions of the camera: V4.02.00, the camera thermal imaging camera: 2.20.0.0.R26130.alpha8 V1.0. Supported hardware versions: V1.0. Supported algorithm versions: smart2.0.0-06-2020.06.17.16:06:42.

Fortuna315 settings#

To subscribe to events, you must create a device with the following settings (Table 85):

Table 85. Fortuna315 Settings

GrgFaster#

The GrgFaster terminal has the ability to display a message on the screen and send the card number to the connected controller.

• Supported devices: GRG Banking Faster.
• Supported models: SV-M082f-C2.
• Supported firmware versions (FW): 1.004.30.3bb324.R.
• Supported Hardware Versions (HW): 1.0.0

Configuring settings for connecting to GrgFaster#

Device settings and possible values (Table 86):

Table 86. GrgFaster Settings

HikvisionCamera#

A camera for generating a video stream for LP5 with subsequent integration with ACS.

• Supported devices: DS-2CD3126G2-IS.
• Supported firmware versions: V5.5.134 build 200430.

The device generates events of type FaceDetectionEvent.

HikvisionCamera settings#

To subscribe to events, create a device with the following settings (Table 87):

Table 87. HikvisionCamera Settings

HikvisionCameraThermo#

A camera with temperature measurement and data transfer functions in LP5.

• Supported devices: DS-2CD3126G2-IS.
• Supported firmware versions: V5.5.134 build 200430.

Events in the queue are of type ThermalEvent.

HikvisionCameraThermo settings#

To subscribe to events, create a device with the following settings (Table 88):

Table 88. HikvisionCameraThermo settings

HikvisionRecognitionOnBoard terminal#

A biometric terminal with face recognition function.

• Supported devices: DS-K1T341AMF, DS-K1T341AM, DS-K1T680D-E1.
• Supported firmware versions: V3.2.30 build 220210.

Open the device's web interface, go to ""Configuration"" → ""Access Control"" → ""Face Recognition Parameters"" → ""Working Mode"" and make sure that the ""Permission Free Mode"" mode is set.

After adding, the faces from the specified list will be replicated to the device's memory. You can add/remove faces in Luna, the changes will be automatically applied to the device.

• the following format of the user_data field is required:

name;card number

• do not set or change the external_id field.

Updating of face data during editing is not supported. If it is necessary to update the data of a person, delete this person and add it again with the necessary data.

Events in the queue are of type FaceDetectionEvent.

HikvisionRecognitionOnBoard settings#

To subscribe to events, create a device with the following settings (Table 89):

Table 89. HikvisionRecognitionOnBoard settings

HikvisionTerminalThermo terminal#

The biometric terminal with temperature measurement, mask detection, and built-in relay.

Only events of the AccessControllerEvent type (having a measured temperature) will be processed, events of this type come from the terminal.

Events in the queue are of type ThermalEvent.

Hikvision terminal with temperature measurement function.

• Supported devices: DS-K1TA70MI-T, DS-K1T671TM-3XF, DS-K5671-3XF/ZU.
• Supported firmware versions: V3.2.32 build 210525.

HikvisionTerminalThermo settings#

To subscribe to events, create a device with the following settings (Table 90):

Table 90. HikvisionTerminalThermo settings

LunaFast2NextGen#

Configuring parameters for connecting to LunaFast2NextGen#

To subscribe to events, you must create a device with the following settings (Table 91):

Table 91. LunaFast2NextGen settings

LunaFast4A1#

The biometric terminal with recognition function.

• Supported devices: DS-K1T341CMF, DS-K1T680D-E1, DS-K1T341AMF, DS-K1T341AM, VL LUNA FAST 4A1, VL LUNA FAST 8A1, 671, DS-K1T671M, ACT-T1341M, DS-K1T680DF-E1, DS-K5671-ZU.
• Supported firmware versions: V3.3.40 build 250106, V3.2.30 build 210415, V3.2.30 build 210525, V3.2.30 build 210526, V3.2.30 build 210812, V3.2.30 build 211025, V3.2.30 build 220607, V3.2.30 build 220803, V3.2.30 build 221027, V3.2.33 build 210816, V3.2.35 build 220415, V3.2.35 build 220817.

Events in the queue are of type FaceDetectionEvent.

To disable the output of the greeting on the terminal screen, you must disable the LunaEventListener pipeline.

Can send card number to controller via device.

The status of card number sending functionality support is displayed in the 'info' block in the hardware_with_card_sending parameter after the component is connected.

LunaFast4A1 settings#

To subscribe to events, create a device with the following settings (Table 92):

Table 92. LunaFast4A1 Settings