Definition
Electronic Turnstile (Electronic Gate) is an automated device used for access control. It works with mechanical structures such as barrier gates, swing gates, and wing gates, combined with authentication methods like card readers, facial recognition, and QR codes to control personnel or vehicle passage. Electronic turnstiles connect to a Device Management Platform via the Internet of Things, enabling remote switching, permission issuance, passage record data collection, device status monitoring, and are widely used in charging stations, business parks, parking lots, and cross-border ports.
In charging station scenarios, electronic turnstiles can control vehicle entry and exit, coordinating with EV charging stations to achieve a "station entry - charging - exit" closed-loop management; at cross-border ports, electronic turnstiles integrate with border inspection and customs systems to achieve automated clearance.
Technical Features and Architecture
The technical features of electronic turnstiles include: Authentication methods — IC card, NFC, QR code, facial recognition, license plate recognition, etc.; Mechanical structure — tripod turnstiles, swing gates, flap gates, sliding gates, etc., suitable for pedestrian or vehicle access; Networking capability — connecting to the platform via 4G/5G IoT SIM cards or wired networks, supporting remote control, permission synchronization, and passage record reporting; Local logic — can operate in a downgraded mode based on the local permission database when offline. Turnstiles need to be integrated with access control systems, parking systems, charging platforms, etc.
In cross-border scenarios, electronic turnstiles need to support local authentication, multilingual interfaces, and IoT SIM cards need one card for multiple countries to ensure stable network connection during cross-border deployment.
Application in IoT and cross-border scenarios
Electronic turnstiles in IoT and cross-border scenarios include:Charging Station——Charging Station Access control at entrances and exits, linking vehicle entry and exit with charging orders;Parks and buildings— personnel access control, visitor management;Parking lots—— Vehicle entry and exit, contactless payment;Cross-border ports—— Integration of port gates with border control and customs systems to achieve automated customs clearance and Data Acquisition. SimtoLink provides IoT connectivity for electronic gates covering over 200 countries, supporting remote management and data feedback in cross-border scenarios.
Access Checks and Fallback When the Network Is Down
The Gate, the Permission, and the Passage Log
In IoT, an electronic gate is field equipment that drives a mechanism to release or refuse from an authorization result, and reports the fact of passage. The check can be a card, a QR code, a plate, or a face. Those only decide what the judgment is based on. The gate itself handles tailgating, closing on timeout, and the fail-open or fail-closed policy. A passage log needs at least time, lane, credential id, release or refusal, and whether a mechanical fault occurred. Remote management can push permissions, open the gate remotely, and see whether it is online. It cannot replace the safety circuit on site. Pedestrian gates and vehicle gates differ in anti-pinch and anti-crush logic. They cannot share one timeout.
When a Local Allowlist Must Be On
The condition depends on whether the business may stop when the network is down. Campus access and a charging-site entrance usually need a local permission store, or a cache of recently successful credentials. When the link breaks, release against the list already synced, and catch up the log after recovery. Where billing is real-time or the QR code is single use, a local check is impossible, so the only choice is to refuse, with a clear prompt on site, rather than a barrier that does not move and a log that does not exist. Permission sync needs a version. The gate may drop the old list only after it confirms the new one. Equipment at a cross-border port also has to follow the local inspection system's interface and time limit. The IoT connection only carries device state and logs that are allowed to be reported. It cannot bypass the formal check.
Requiring a Live Check on Every Passage During an Outage
A common mistake designs every lift of the barrier to wait for a cloud reply. When roaming or the local cell is congested, vehicles block the entrance, while the site already holds a valid list. Another mistake releases during an outage and does not cache the log. After recovery there is nothing to reconcile, and the charging order does not match the exit record. Unsynchronized time makes a permission expire early, or lets an expired credential still pass. A remote open with no operator and no reason cannot be audited later. A failed anti-tailgate sensor is ignored, and the gate still reports "passage succeeded." When the mechanical count and the authorization count disagree, alert, rather than trusting only one side. Shown together with device status, separate "online but the list is expired" from "offline but local release is allowed." Otherwise maintenance cannot tell whether to repair the network or refresh permissions.
The list version follows the gate's confirmation. If the platform shows the list as delivered and the gate still uses the old one, an expired credential keeps passing, or a new credential is refused. When an outage allows release, write the log locally first and catch it up by the time it happened, not by the time of the upload. A single-use QR code that cannot be checked locally should be refused, with a prompt on site, rather than a barrier that does not move and no record. Pedestrian and vehicle anti-pinch timeouts cannot be shared. A remote open records the operator and the reason. Alert when the mechanical count and the authorization count disagree. Online with an expired list, and offline while local release is still allowed, are two different responses. Once the screen separates them, it is clear whether to repair the link or to sync permissions again.
Fail-open and fail-closed must be set per lane by risk. An evacuation lane must be able to open when power is lost. Whether a paid exit may pass when power is lost must be set in advance. The whole site cannot share one relay logic. Catch-up logs and live logs use the same sequence space, so recovery does not create two identical passage records.