Protocol choice is a system decision, not a checkbox
Choosing between RS-485, CAN and Ethernet should start from what each layer has to do: how many devices share a cable, how far apart they are, whether events are polled or unsolicited, how noisy the route is, and whether a link outage may stop a door from opening. The recurring faults integrators see — intermittent reads, nodes dropping off, "works on the bench, not in the riser" — usually trace back to a bus used outside its comfort zone: a star-wired RS-485 line, an unterminated pair next to a contactor coil, or an IP link in the critical path of a door.
It helps to think in three tiers: reader to controller (a few metres, polled, must be encrypted), node to site master (dozens of nodes on a long riser, unsolicited events, fault containment) and master to cloud (bandwidth, TLS, outside the access decision). AXON maps one bus to each — RS-485, CAN and Ethernet.
RS-485: the reader and relay bus
RS-485 (TIA-485-A) is balanced differential signalling on one shielded twisted pair, wired as a linear multi-drop bus with 120 Ω termination at the two physical ends only. It is noise-tolerant and cheap per node, and every door, gate and light is already at the end of a wire run, so the same pair can carry the command that closes the relay beside each one. That is why the RBN-2 and SC-E relay nodes, the SSR-32 output board, the AMS Wiegand converter and the PBC-Bridge all sit on RS-485.
It is also the reader link. The URX-Secure DESFire EV3 reader talks half-duplex RS-485 at 115200 bps, 8N1, using the AXON binary frame (SOF 0xA5, addresses, command, length, CRC16-CCITT). Inside it runs a secure layer: 3-pass mutual authentication between reader and master, a per-session AES-128 key, and every access frame AES-CTR encrypted then tagged with an 8-byte CMAC and a per-direction counter. Replayed or forged frames are dropped; eight bad frames trigger a 5 s lockout. The CCU-32 cabin master polls readers every 700 ms, and the floor Node runs the same protocol implementation, so one reader firmware serves cabin and landings.
Discipline matters more than the standard: terminate only at the two ends (about 60 Ω across A/B with all modules powered down), keep stubs to 30 cm or less and daisy-chain rather than star, route the pair away from mains and contactor-coil cabling, keep reader runs under 30 m, and record every address in the as-built.
Where RS-485 stops making sense is the backbone tier: one master polling sixty nodes across a riser adds latency with every node, has no hardware arbitration for unsolicited events and no error confinement when one board misbehaves.
CAN: the floor-node backbone
CAN was built for long, noisy multi-drop buses with many nodes, and it brings in hardware what RS-485 lacks: non-destructive arbitration, error detection with fault confinement, and per-ID acceptance filtering. Across a riser with dozens of nodes that is the better fit, which is why the AXON Node bridges each landing's RS-485 reader onto a CAN backbone to the ICM-GE master.
The AXON backbone runs Classic CAN 2.0B with 11-bit identifiers at 250 kbit/s and an 87.5 % sample point, 120 Ω at both physical ends, short stubs. The arbitration ID encodes direction, node ID and message type, so every ID has exactly one legal transmitter. Node IDs run 0–62 (63 is broadcast), set on a DIP switch — 63 nodes per port — and the ICM-GE has two independent ports, so a tall riser can be split lower/upper and a faulty segment powered down without touching the rest of the building. A 20-floor tower with roughly 80 m of bus is well inside margin. 250 kbit/s is deliberate: higher rates cut usable bus length, and the Node's STM32F072 bxCAN has no CAN-FD anyway.
The timing and failure behaviour are what make it a backbone:
- Measured tap-to-verdict on the Node is under 10 ms; the ICM-GE decision target from its 4 MB on-board card database is under 2 ms.
- If the master's verdict does not arrive within 800 ms the tap expires as a deny — fail-closed.
- Five consecutive CAN errors trigger a 30 s pause and a full re-initialisation; a status frame every 5 s lets the master re-authenticate a rebooted node at once, and 63 nodes authenticate at boot in about 1.3 s.
Security is per node: each Node holds its own AES-128 key derived by AES-CMAC from the master's root key and the node ID, traffic is encrypted then MACed with 4-byte counters, and the arbitration ID is bound into the MAC so a frame cannot be replayed to another node. A compromised node exposes that node alone; a failed MAC drops its session and forces re-authentication. CAN is not used everywhere: inside the cabin the CCU-32 talks RS-485 to a few readers, and CAN is never the uplink. The Node deep-dive documents the full bus contract.
Ethernet: the uplink, not the door
Ethernet is the right transport for the management plane — dashboards, event aggregation, remote firmware — and the wrong place to put a door decision. Both AXON masters carry a W5500 10/100 Ethernet controller as the primary route to the AXON cloud, speaking MQTT over TLS to AWS IoT (port 8883 on the ICM-GE), with firmware fetched over HTTPS into a staging slot and applied only after verification. Put the master on a dedicated switch port or a managed VLAN and keep that network under change control.
The uplink is best-effort by design. The ICM-GE carries an A7672E LTE Cat-1 modem and a SIM slot, but cellular data transport is still in development, so Ethernet is the shipping uplink; on the CCU-32 a SIM7000G LTE-M / NB-IoT modem covers cabins with no cabling at all. When the uplink is down the master keeps deciding from its last synchronised database, events are recorded locally, and everything reconciles when the link returns.
Why not Ethernet to every door? An IP stack per relay or per floor needs structured cabling, a switch port, an IP plan and a security boundary at each node — for what is fundamentally a set-channel-state command. An Ethernet/PoE drop and controller per floor is exactly what the CAN backbone replaces.
Side by side
| RS-485 | CAN | Ethernet | |
|---|---|---|---|
| Role in AXON | Reader and relay bus | Floor-node backbone to ICM-GE | Cloud uplink from the master |
| Topology | Linear multi-drop, 120 Ω both ends, stubs ≤ 30 cm | Linear, 120 Ω both ends, two ports on ICM-GE | Star through a switch, one port per master |
| Devices | One master polls addressed slaves | Up to 120 access points per port (63 addressed nodes), hardware filters | Master only; LTE modem fitted alongside |
| Rate | 115200 bps 8N1 half-duplex | 250 kbit/s Classic CAN 2.0B, 11-bit IDs | 10/100 Mbps |
| Security | 3-pass mutual auth, AES-CTR + CMAC, counters | Per-node AES-128 keys, encrypt-then-MAC, ID bound into MAC | MQTT over TLS, verified HTTPS OTA |
| Best for | Readers, relays, retrofit converters, cabin bus | Risers with dozens of nodes | Management, logs, OTA, dashboards |
Reference layouts that mix all three
- Elevator cabin — URX-Secure → RS-485 → CCU-32 → 32 relays into the call-button matrix; Ethernet or LTE-M uplink. See How elevator access control works.
- Landings, entrances and doors — URX-Secure → RS-485 → Node → CAN → ICM-GE → Ethernet uplink; relay expansion on RS-485 next to the load. See Access control for multi-entrance buildings.
- Distributed site — ICM-LR uses LoRa (up to about 1 km line-of-sight, EU 868 MHz) between locations where trenching does not pay, with a short local RS-485 bus at each point; sync, logs and OTA still go over the wired uplink, never over LoRa.
- Retrofit — AMS behind existing Wiegand 26/34 readers and PBC-Bridge on legacy push-button lines both publish onto the RS-485 bus, so an old site joins the same addressed, encrypted fleet without new reader hardware.
Whichever layout applies, document the design on day one — node IDs and RS-485 addresses, which floors sit on which CAN port, where the terminations are, and what each tier does when its link is lost. That is how the next technician isolates a fault in minutes rather than a day.
Key takeaways
- Match the bus to the tier: RS-485 for short polled reader and relay links, CAN for the multi-node riser, Ethernet for the cloud.
- Keep the access decision on the master, on the local bus. Ethernet and cellular synchronise and report; they never grant.
- Terminate at the two ends, keep stubs short, avoid stars and keep signal cabling away from mains and coils; encrypt every tier.
Frequently asked questions
Is Ethernet always better than RS-485 for access control? No. Ethernet is the right transport for central integration, event streams and firmware, and AXON masters use it as the primary uplink. RS-485 is better for the field links themselves — short, polled, noise-tolerant, cheap per node — and keeps working when the LAN does not.
When should CAN be used instead of RS-485? When many nodes share a long backbone and send unsolicited events: hardware arbitration, error confinement and per-ID filtering do in silicon what a polled RS-485 line must do in software. In AXON that is the riser between the Node and the ICM-GE. Inside a cabin, with a few readers, RS-485 is sufficient.
Can protocols be mixed in one system? Yes — a complete AXON site always is: RS-485 from reader to node or cabin master, CAN from node to building master, Ethernet or LTE from master to cloud. Each hop has its own encryption and failure behaviour, and the decision never leaves the on-site master.
Does the door still open if the network is down? Yes. The ICM-GE holds the full card database on board and decides offline; the Node fails closed after 800 ms only if the master itself is silent. Loss of Ethernet and LTE affects sync and reporting, not access.
Related: Smart building access control · Anti-cloning RFID with DESFire EV3 · Technical documentation