Introduction to Operating Modes

ControliD's access controllers are programmed to work in different operating modes that suit different customer use cases.

The possible interactions between the server and the control access terminal will be determined by the operating mode used. The operating modes described below can be split into two categories: standalone or online.

In applications developed for terminals in standalone operating mode, the communication will be unilaterally from the server to each terminal, and the server must be concerned to keep the users' data and the access rules up to date.

In another way, for applications developed for terminals in some online operating mode, the communication flows both ways because the logic of authorization and identification will be partially or totally on the server.

There are two online operating modes: Enterprise Mode and Pro Mode. Their principal difference lies in which access treatments are delegated to the external server and, therefore, in what kind of information it should receive.

Operating Modes Mode	Identification	Authorization	Information sent in the access attempt
Standalone	On terminal	On terminal	-
Pro	On terminal	On server	User ID
Enterprise	On server	On server	User biometrics
Contingency	On terminal	On terminal	-

Standalone Mode

Identification and authorization on terminal

This is the operating mode recommended by Control iD.

A device is in Standalone Mode when the online configuration is disabled.

In this mode, the device must have all the information needed for identification and authorization stored in its database, namely, users enrollers, biometrics/cards, departments, time, and access rules.

To work remotely in this mode, you just need to send the wanted requests to the device's API.

Thus, both identification and authorization treatments are made totally on terminal.

In the Standalone mode, the information flows just in one way: from the server to the device.

Pro Mode

Identification on terminal and authorization on server

A device is in Pro Mode when the online configuration is enabled and the local_identification configuration is also enabled.

In this mode, when a user starts a biometric identification on the device, it will analyze the received data through its own biometric algorithm and identify the correspondent user in its local database.

Only the identified user iD is sent to the server, where the access rules will be processed and

Only the identified user ID is sent to the server, which will process the access rules to determine whether or not to grant authorization.

Thus, the identification treatments are made totally on terminal while the authorization treatments are made totally on server.

Note that, using this method, the server must always keep users and their biometric data updated in the device, restricted to the limitation of existing records. This limitation is described in the topic Number of templates limitation.

Enterprise Mode

Identification and authorization on server

A device is in Enterprise Mode when the online configuration is enabled and the local_identification configuration is disabled.

In this mode, when the user starts a biometric identification on the device, it will only send an image of the biometrics to the server. It is up to the server to make use of some biometric algorithm to process the user's authorization.

Thus, the identifications and authorizations treatments are made totally on the server.

Contingency Mode

Identification and authorization on terminal

If a device operating in one of the online modes cannot communicate with the server for three consecutive attempts, it will enter contingency mode. This is an exception mode and cannot be used by default on devices. The number of attempts to communicate with the server is a configurable parameter.

In this mode, all identifications are made using exclusively local records of the device, which must be updated. This operating mode is equivalent to the Standalone Mode.

While in contingency, every minute, the device will send a new request POST/device_is_alive to the server. As soon as it gets a response (HTTP OK status code), it will revert to its original mode of operation.

Thus, both identification and authorization treatments are made totally on terminal.