What "smart" should mean for access control
Connected is not the same as cloud-dependent. A reader that must ask a remote server whether a card is valid adds latency to every tap and stops working when the internet does. A smart building needs three things from its access layer:
- One policy, applied everywhere. A card revoked once at the management plane is refused at every reader on its next presentation.
- One event stream. Every grant and deny, with the reason, arrives in one place where operators and other building systems can consume it.
- Local autonomy. Doors and elevators keep working through a network outage, and the audit trail is not lost while the link is down.
AXON is built around exactly that split: decisions at the edge, management in the centre.
The AXON architecture inside a building
An AXON site has two decision-making controllers and a set of nodes and readers that never decide on their own.
| Layer | Hardware | Link | Role |
|---|---|---|---|
| Credential capture | URX-Secure reader (MIFARE DESFire EV3, AES-128 mutual auth) | RS-485, encrypted | Proves the card holds the key, reports a CARD_EVENT — never grants on a UID alone |
| Floor / door node | AXON Node | RS-485 down to the reader, CAN 250 kbit/s up to the master | Forwards the event, waits for a verdict, pulses two relays only on a master command |
| Building master | ICM-GE | Two independent CAN buses, up to 120 access points each | Holds the on-board card database (up to 32,704 cards) and decides locally, target under 2 ms |
| Cabin master | CCU-32 | RS-485 to the in-cabin reader | Decides which floors a card may reach and pulses one relay per floor button |
| Output expansion | RBN-2, SC-E | RS-485 | Switch strikes, maglocks, barriers and signals next to the load |
| Uplink | Ethernet (LTE modem fitted, in development) | MQTT over TLS, port 8883 | Database sync, event batches, OTA — never the access decision |
Two details matter at building scale. The same reader board and firmware serve the cabin and the landings; only the bus address differs. And the ICM-GE has two CAN ports, so a tall riser can be split — lower floors on one segment, upper floors on the other — and a faulty segment powered down without touching the rest of the building. Topology is covered in Access Control for Multi-Entrance Buildings and RS-485 vs CAN vs Ethernet.
Where the decision is made
AXON can be centrally managed without being centrally dependent because the master owns the decision:
- The ICM-GE keeps every card as a sorted 64-byte record in on-board memory, so a lookup is a binary search with a design target of under 2 ms. Existence, blocked flag, permission mask and RTC validity are checked in that order.
- The Node waits at most 800 ms for a verdict. If none arrives, the tap expires as a deny — fail-closed, not fail-open.
- The CCU-32 decides on the board and pulses the granted floor relays for 3 seconds so the passenger can press those buttons on the original panel. No server sits in the critical path.
- Every GRANT and DENY, with its reason — unknown card, expired or revoked, no permission for that node — is recorded the moment the decision is made and reported to the server with the master's telemetry.
Operators still see one building; the building simply does not wait for them.
Centralized management: what the cloud actually does
Each master's uplink is MQTT over TLS on port 8883 — a W5500 Ethernet controller on the ICM-GE, and Ethernet with an LTE-M / NB-IoT modem on the CCU-32. The ICM-GE carries an LTE Cat-1 modem whose data transport is still in development. Over that link the management plane does three jobs and only three:
- Database sync. New users, revoked cards, changed permissions and validity dates are pushed to every master that needs them.
- Log collection. Access events are collected from the masters into the central audit trail.
- Firmware delivery. Updates arrive over HTTPS into a two-slot OTA layout that is verified before it is applied.
The link is best-effort by design: when a hospital's WAN drops, decisions continue locally and events are held until sync resumes. Give each master a dedicated switch port or a managed VLAN — it belongs on the management network, not the tenant network.
Visibility, audit and the rest of the building stack
Centralised telemetry is what turns access control into a building-management input. Each master publishes card events, relay commands and status over MQTT, so the data that feeds the AXON dashboard can also be consumed by whatever the building already runs:
- Occupancy-driven services. A first-in / last-out signal per floor can drive HVAC set-back or corridor lighting at the BMS layer.
- Anomaly review. Repeated denies at one landing, taps at unusual hours or a burst of expired-card presentations show up in one log instead of across panels.
- Tenant reporting. In a multi-tenant office each tenant's floors are a floor mask; per-tenant reports come from the same stream.
The boundary is deliberate: the access hardware publishes events and executes verdicts; cross-system logic lives at the platform or BMS layer. That keeps every board small, auditable and replaceable.
Interoperability for integrators and retrofits
Most buildings are not greenfield. AXON keeps the encrypted backbone while giving integrators practical entry points:
- Existing Wiegand readers. AXON AMS (W2R-N) sits behind a Wiegand 26/34 reader and republishes each credential on the AXON RS-485 bus, shrinking the cleartext Wiegand run to a few centimetres inside the back box.
- Older elevator cabins. PBC-Bridge taps the existing push-button lines and frames them as AXON BUS events, so the cabin can be gated without touching the certified controller wiring (in development, field pilots).
- Direct elevator integration. ELM-GE sends a real destination call to the elevator controller instead of simulating a button press (in development, pilots on request).
- Distributed sites. ICM-LR reaches remote gates up to about 1 km line-of-sight over LoRa, with a local RS-485 bus at each point and the decision still on the master.
Every one of these devices follows the family rule: it never decides. Policy changes once, at the master, and the whole building follows.
Kosovo and the region
The same architecture serves a twenty-floor tower in Prishtinë, a mixed-use complex with an underground garage or a managed residential block. Modules ship from local stock in Kosovo, the CAN backbone and reader configuration are sized per building, and firmware is supported by the team that designed the boards. Scale and topology change between projects; the need for stable bus communication, consistent policy and credentials that cannot be cloned does not — see Anti-Cloning RFID for why DESFire EV3 replaces Wiegand-26 in new installs.
Frequently asked questions
Does the building stop working if the internet goes down? No. Decisions are made on the ICM-GE and CCU-32 from their local card databases. The uplink carries only database sync, log batches and OTA firmware, so an outage delays reporting, not entry.
How is a revoked card blocked everywhere? The revocation is applied once at the management plane and synchronised to each master over MQTT/TLS. Every reader reporting to that master refuses the card on its next presentation.
How does AXON feed other building systems? Through the MQTT event stream published by each master. Occupancy, lighting or HVAC logic is implemented at the BMS or platform layer that subscribes to those events, not on the access boards.
Can we keep the readers we already have? Yes, with the AXON AMS (W2R-N) converter behind each existing Wiegand 26/34 reader. For new installs the URX-Secure DESFire EV3 reader authenticates the card with AES-128 before it reports anything.
What bus should we plan for a tall building? Encrypted RS-485 from reader to node, and 250 kbit/s CAN from nodes to the ICM-GE — up to 120 access points per port (240 per master) across two independent ports, so a riser can be split into segments — and masters combine for larger sites.
Explore the modules in the AXON Store or contact us to size a system for your building.