AXON Elevator Master
The elevator master tier of the AXON platform. It validates a credential against stacked access policies and sends a real destination call to the elevator controller — not a simulated button press.
A real call, not a fake button press
AXON ELM-GE is the master controller for elevator-class AXON installs. Three communication domains meet on the board: Ethernet and GSM upstream to the central AXON platform for credential sync, audit offload and remote management; an RS-485 bus downstream to landing readers, converters and output expansion modules; and a direct command path into the elevator controller itself. When a credential passes validation, ELM-GE issues a destination command over the controller's own interface, so the call enters the controller's scheduler as a normal request rather than as a contact closed across a floor-button input.
That distinction is the load-bearing design choice. Button simulators work mechanically but are invisible to group dispatch, destination dispatch, priority handling and service modes, and they cannot be logged as a real call event on the elevator side. Direct integration keeps the controller's dispatch intelligence intact and produces a log entry on both sides. In a full ELM-GE deployment the landing hardware reduces to a reader; the floor-button matrix becomes largely optional, with a small override panel kept for service and emergency use where the building wants one.
Validation stacks six policy layers before any command is issued: credential identity, time window, per-credential floor list, priority class, lockdown state and active override or VIP flags. Denials are logged with the layer that failed. ELM-GE then supervises the controller's response and flags a rejected or ignored call as an anomaly. Cached policy and a local audit buffer keep access working and records intact through a brief uplink outage. The product is in development; the role and capability set are stable, while controller integrations, uplink security profile and production hardware details are being finalised.
What the board does for the site
Direct elevator controller command
On a validated credential ELM-GE issues a destination command through the controller's own command interface — serial, CAN or Ethernet depending on the make. The call is treated identically to a manual destination request, so group and destination dispatch, priority handling and service modes keep working above the access layer.
Ethernet primary, GSM fallback
Ethernet 10/100 Mbps carries credential sync, audit offload and management traffic. A GSM or cellular modem takes over for management and emergency commands when the building LAN drops — a common event in elevator machine rooms. GSM is a lifeline, not a continuous data path, so its data use stays small.
RS-485 bus to readers and modules
Downstream, one half-duplex RS-485 bus (TIA-485-A) reaches URX-Secure readers, AMS Wiegand converters and RBN-2 or SSR-32 output modules. Each device carries an individual address per the AXON bus convention; the master polls them over shielded twisted pair with 120 Ω termination at both physical ends.
Six-layer policy stack
Every credential event passes identity, time window, per-credential floor list, priority class, lockdown state and any active override or VIP flag before a command goes out. Each layer passes or denies; a denial is logged with the failing reason and no controller command is issued, so operators see failures rather than silence.
Cached policy and local audit
The credential cache is populated from the central platform over Ethernet or GSM. If both uplinks are down, ELM-GE keeps honouring cached policy for a configurable offline grace period and buffers every event locally. When either uplink returns, queued events upload; a full buffer is itself a logged event.
Battery-backed RTC and NTP
Time-window policy collapses without reliable time, so ELM-GE carries a real-time clock with battery backup and syncs to NTP over Ethernet. Audit timestamps and time-of-day rules survive power cycles even when the uplink is unavailable at boot.
One credential, one real destination call
Credential read
A resident presents a card at a landing reader. The reader sends the credential over the RS-485 bus to ELM-GE.
Identity and policy stack
ELM-GE resolves the credential in its local cache, then applies time window, floor list, priority, lockdown and override layers. Any denial is logged with its reason.
Direct controller command
On a full pass ELM-GE resolves the destination floor and issues a destination command through the elevator controller's own command interface.
Reconcile and report
ELM-GE supervises the controller's response, logs an accepted call as an authorisation or a rejected one as an anomaly, buffers the event and pushes it upstream.
Three legs meet in one machine-room cabinet
Ethernet primary, GSM fallback
Ethernet 10/100 Mbps (IEEE 802.3) to the building LAN is the primary path for credential sync, audit log offload and management. A GSM or LTE-class modem, per 3GPP standards and depending on the modem fitted, keeps the master reachable for management and emergency commands when the LAN is down. The two paths are deliberately asymmetric.
IEEE 802.3 · 3GPP cellular fallbackRS-485 bus in the riser
A linear RS-485 backbone (TIA-485-A) runs through the building riser with short stubs to each landing reader, converter and output module. Every device has an individual address. Shielded twisted pair, 120 Ω termination at the two physical ends only, no star topology and no termination at every device.
TIA-485-A · 120 Ω at both endsElevator controller interface
The unique leg. ELM-GE talks to the elevator controller over the controller's own command interface — destination command, floor lock-out, service-mode entry, whatever the make exposes. Physical and protocol layer vary: some controllers use serial, some a dedicated CAN variant, some Ethernet. An integration layer hides those differences from the policy engine.
Serial · CAN · Ethernet, per makeThe numbers, from the datasheet
Target interface layout from the development spec. Supply voltage, MCU, dimensions, cellular bands, audit storage capacity and certifications are not final and are omitted.
| Role | Elevator master controller |
|---|---|
| Access decision | Local, from cached policy |
| Elevator link | Direct controller command — not button simulation |
| Policy layers | Identity, time, floor list, priority, lockdown, override |
| Audit | Local event buffer with offline replay to platform |
| Status | In development |
| Primary uplink | Ethernet 10/100 Mbps, RJ45 (IEEE 802.3) |
|---|---|
| Fallback uplink | GSM / cellular modem, SIM slot, external antenna |
| Downstream bus | RS-485 A/B/GND, half-duplex (TIA-485-A) |
| Bus termination | 120 Ω at the two physical ends only |
| Bus devices | URX-Secure, AMS (Wiegand), RBN-2, SSR-32 |
| Elevator interface | Serial, CAN or Ethernet — depends on controller make |
| Power input | Dedicated DC feed with margin for GSM modem peak draw |
|---|---|
| Supervision | Board power supply with watchdog |
| Real-time clock | Battery-backed RTC |
| Time source | NTP over Ethernet, RTC across power cycles |
| Validation | Six policy layers, denying layer logged |
|---|---|
| Reconciliation | Controller response supervised, anomalies logged |
| Life safety | Fire-service / emergency mode overrides ELM-GE |
| Key storage | Secure element / TPM — planned |
| Uplink security | TLS / mutual-auth profile being finalised |
| Dry-contact inputs | Fire alarm interlock, override panel — planned |
| Mounting | Sealed enclosure in or adjacent to machine room |
|---|---|
| Isolation | Away from the drive cabinet; own cable trunking |
| Antenna | GSM antenna routed outside the machine room |
| Status indicators | Uplink state, bus activity, controller link |
Terminals & connectors (target layout)
Primary uplink to the building LAN. Patch to a switch port that survives building network maintenance, not a shared printer hub.
Fallback uplink. External antenna recommended, routed out of the machine room; verify signal with a survey before commissioning.
Downstream bus, daisy-chained to landing readers, converters and expansion modules. 120 Ω termination at the two physical ends only.
Direct integration. Layout depends on the supported controller make; run in its own trunking, label both ends, do not splice in the field.
Board supply. Dedicated DC feed sized for the board plus margin for GSM modem peak draw.
Fire alarm interlock and override panel — life-safety inputs that take precedence over access logic.
Uplink state, bus activity and controller link state for at-a-glance commissioning and triage.
How ELM-GE compares to elevator retrofits
| Aspect | AXON ELM-GE | Button simulators & dry-contact retrofits |
|---|---|---|
| Elevator link | Destination command over the controller's own interface | Contact closed across a floor-button input, or dry-contact go/no-go per floor |
| Dispatch intelligence | Group and destination dispatch, priority and service modes preserved | Invisible to the controller's higher-level features |
| Logging | Real call event logged on the controller and on ELM-GE | Cannot be logged as a real call on the elevator side |
| Landing hardware | Reader only; button matrix largely optional | Full call panel remains, brittle when the panel changes |
| Vendor lock-in | Brand-agnostic credentials, per-make controller integration | OEM access modules are manufacturer-locked with their own credential platform |
AXON Elevator Master, up close
Photographs are not published yet
AXON ELM-GE is in development. Board photographs, final pinout and electrical ratings are released together with the production unit. Ask us for the current engineering status.
Where AXON ELM-GE fits
Typical configurations we size for integrators. Every scenario below is a planning example, not a customer reference.
Reader-only landings in a high-rise tower
A new 25-floor residential tower installs ELM-GE in the elevator machine room. Each landing carries only a reader, no full button panel. A resident presents a card, ELM-GE validates the credential against the resident's authorised floors and issues a destination command; the cabin arrives with the floor already selected. Guests use temporary credentials, staff a separate priority class.
Floor-by-floor tenant separation
A 14-floor office building uses ELM-GE to enforce access by tenant. Tenant A occupies floors 3 and 4, tenant B floors 5 to 8, building services floors 9 to 14. One elevator serves everyone, but each credential can only call its authorised destinations. In a security incident a lockdown from the platform makes ELM-GE deny everything below a configured tier.
Staff-only floors on shift windows
A hotel reserves its top two floors for back-of-house areas. ELM-GE refuses to call those floors for any guest card while serving guest floors normally. Cleaning staff hold a priority class that authorises the staff floors only during their shift windows. Every authorisation and every denial is logged, including the policy layer that denied it.
Ward access without losing dispatch
A hospital main elevator block enforces ward-by-ward access. Medical, administrative, cleaning and contractor staff each have a credential class with its own floor list and time windows. Visiting hours open and close visitor floors automatically. Because ELM-GE talks to the controller directly, group dispatch — cabin selection, wait-time optimisation — keeps operating while access is filtered upstream.
AXON ELM-GE FAQ
What does direct elevator controller integration actually mean?
Why both Ethernet and GSM?
Are floor buttons still needed?
Which elevator controllers does ELM-GE integrate with?
What happens during a fire or emergency event?
Is ELM-GE shipping today?
The rest of the AXON system
Ready to specify AXON ELM-GE?
ELM-GE is in development. Share your elevator controller make and model and the building's floor plan; AXON confirms the integration path, sizes the RS-485 bus and reader count, and can arrange a pilot on a planned install.