AXON PBC-Bridge — Push-Button & Legacy Signal Converter to AXON BUS

A converter module that bridges existing elevator push-button lines and legacy protocol signals into the AXON BUS, so a non-invasive retrofit can put a modern access controller in front of an old elevator installation without touching the existing cabin wiring or controller certification.

01 — What AXON PBC-Bridge Does in the System

AXON PBC-Bridge is the retrofit converter in the AXON access architecture. Its job is narrow on purpose: take the signals that already exist on a legacy elevator installation — discrete push-button lines from the cabin and landings, plus various legacy protocol signals used by the elevator's drive and controller — and translate them into AXON BUS frames that the rest of the AXON ecosystem already understands.

Functionally, the bridge sits between two worlds. On one side it speaks to the legacy installation in its native electrical language: discrete contacts, voltage levels, timing patterns set decades ago by the original elevator manufacturer. On the other side it speaks AXON BUS, which is the standardized communication format used by every other module in the AXON family. The bridge is the only place in the topology where those two languages meet, and it absorbs all the irregularity of the legacy side so that nothing further up the stack has to deal with it.

The architectural reason this matters is simple: replacing an elevator controller is expensive, regulated under EN 81-20 and the related test methods in EN 81-50, and almost always overkill when the actual goal is to add modern access control. The motors, safety circuits, and travel logic that already work in the existing controller should keep working untouched. What needs to change is who is allowed to call the cabin, where, and when. The PBC-Bridge isolates exactly that signal layer and hands it to the AXON Master without disturbing anything else.

A typical operational flow looks like this: a resident presses a landing call button, or an existing legacy signal asserts on the elevator controller's I/O; the PBC-Bridge senses the change on its input side; the bridge frames the event as an AXON BUS message and emits it; the AXON Master receives the event, applies the relevant permission and time-window policy, and either allows the elevator to proceed or refuses the call; in Bridge mode the response is converted back into a legacy-compatible signal and asserted on the elevator controller's input. The existing elevator behaves as if its own buttons were being pressed by an authorized user.

02 — Required Components

The PBC-Bridge ecosystem in a retrofit installation involves the following components:

Part	Role	Notes
AXON PBC-Bridge module	Signal converter	Maps legacy push-button and protocol signals to AXON BUS frames. Mode (Converter / Bridge) is selectable.
AXON Master	Authoritative controller	Holds permission policy, time windows, audit log. Treats the bridge as an AXON BUS node.
Existing elevator controller	Motor and safety logic (untouched)	Continues to run all motion-critical logic. The bridge only interacts with its access-relevant I/O.
12 V or 24 V DC supply	Power	Module accepts either rail. Choice is made by terminal wiring in the cabinet.
AXON BUS cabling	Communication backbone
Optional AXON Nodes / Readers	Access input devices	RFID readers and floor nodes added at landings feed into the same Master and share the audit log.

Why these specific parts

The split between PBC-Bridge and Master is deliberate. The bridge is a converter and only a converter — its responsibility ends at framing the signal and putting it on the AXON BUS. Permission logic, schedules, lockdown, and audit live one layer up on the Master. That separation means the bridge stays small and reliable, and the Master stays general-purpose: it does not need to know whether an event came from a native AXON Node or from a retrofitted PBC-Bridge attached to a 1990s elevator controller. Both look identical on the bus.

Accepting both 12 V and 24 V DC reflects a simple field reality: there is no consistent control-rail voltage across the elevator installed base in the region. A single SKU that handles either rail eliminates an extra step-down or step-up converter in the cabinet and avoids the SKU sprawl of "PBC-Bridge-12 V" versus "PBC-Bridge-24 V" variants.

03 — How the PBC-Bridge Works End-to-End

The bridge's operational loop is intentionally short. Every step is bounded so that a stuck signal on the legacy side never produces an indefinite event on the AXON side.

1. Signal sampling. The bridge continuously samples its inputs — the push-button lines and the relevant legacy elevator protocol signals — looking for state transitions.
2. Debounce and filter. Legacy contacts bounce; that is universal. The bridge filters transients so a noisy contact does not flood the bus with phantom events.
3. Logical isolation check. The signal is interpreted in the bridge's own logical frame, not propagated raw. A fault or unexpected level on the legacy side is contained at this stage and does not become an AXON BUS event with undefined semantics.
4. Frame the event. The bridge encodes the event as an AXON BUS message: device address, event type, payload. The framing is identical to any other AXON BUS device, so the Master applies its usual handling.
5. Transmit on AXON BUS. The framed event is published on the bus and received by the AXON Master, which logs it and applies the authorization policy.
6. Receive command (Bridge mode). If the bridge is configured in Bridge mode, the Master's response — allow or deny, plus any associated control signal — comes back over the AXON BUS.
7. Drive legacy output. In Bridge mode the bridge asserts the appropriate signal on its output side, in a form the legacy elevator controller already understands.

Each step is bounded by a timeout. If the AXON Master does not respond within the configured window for a given event, the bridge applies the configured failure policy — typically "deny" for access events, since silently allowing access on a comms failure is the worse failure mode in a multi-tenant building.

04 — Communication Architecture

Legacy side

On the input side the bridge speaks to the existing elevator installation in its native electrical language. That is necessarily heterogeneous: a building from 1998 with a manufacturer-A controller looks nothing like a building from 2012 with a manufacturer-B drive. The bridge accommodates this by treating each input channel as a configurable signal type, sampled and interpreted according to the channel's configuration. The general principle is that the bridge adapts to the building, not the other way round.

AXON side

On the output side the bridge speaks AXON BUS. The physical layer follows the differential signalling defined in TIA-485-A (RS-485), which is the industry baseline for multi-drop industrial busses. From the Master's perspective the bridge looks like any other addressable node: it has an address, it publishes events, it accepts commands. The Master does not have a special code path for "bridges" — that uniformity is the point of putting a converter at the edge in the first place.

Why a bus rather than a point-to-point link

A bus topology lets multiple PBC-Bridge units, multiple AXON Nodes, and the Master share a single backbone running through the elevator riser or building riser. It scales by addition: more devices means more addresses on the same bus, not more cabling back to the Master. In a retrofit, that matters: the existing cable trays are usually full and pulling new home runs to every device is the single most expensive part of the job.

Central vs local validation

The bridge integrates with the AXON Master for central or local validation. Central validation means every access event is referred to the Master, which holds the live permission set; this gives a single source of truth and centralized audit, but introduces a round-trip latency on every event. Local validation is for fast paths — for example, repeated calls from a credential the Master recently authorized — where caching a recent decision saves a round trip. The cache is always subordinate to the Master: if the Master revokes a credential, the next central refresh invalidates the local cache. The exact cache window is a deployment parameter.

05 — Interface Layout

Final pinout and terminal layout are being finalised as part of the development phase. The functional groups that any released revision will expose are:

Group	Function	Notes
Input — button lines	Sampling of existing push-button signals	Channel count and input range to be confirmed at release.
Input — legacy protocol	Legacy elevator controller signal interface	Exact protocol set under validation in field pilots.
Output — legacy drive	Asserts signals back into the existing controller (Bridge mode)	Disabled in Converter mode.
AXON BUS A / B	Differential bus pair to the AXON backbone
Power IN	12 V or 24 V DC	Rail selection by terminal wiring; reverse polarity protection to be confirmed at release.
Ground	Module ground	Single-point ground at the cabinet recommended to avoid loops.
Mode select	Converter / Bridge selection	Mode selection method (DIP switch or configuration) to be confirmed at release.

The pinout is being deliberately kept conservative: standard screw or pluggable terminals on a DIN-rail-compatible form factor. The intent is that an electrician already familiar with elevator cabinet work can install the bridge without specialized tooling, in the same way a contactor or interface relay would be wired in.

06 — Security and Robustness

The bridge has two distinct robustness concerns, one on each side.

Legacy-side robustness

Legacy elevator wiring is electrically noisy: contactors switching, motor inrush, and decades-old insulation conspire to inject transients. The bridge handles this with input filtering and debounce so that a noisy contact does not produce a stream of phantom events on the AXON BUS. Logical isolation of the signal layer — implemented in line with the optocoupler safety and insulation requirements of IEC 60747-5-5 — ensures a fault on a single legacy input cannot propagate as a broader failure: the affected channel reports its state, but the rest of the module and the rest of the bus continue normally.

AXON-side security

On the AXON side the bridge is an AXON BUS node, and inherits the security posture of the bus it sits on — addressing, framing, and any encryption that the platform applies. Critically, the bridge does not store user credentials or permissions locally beyond any short-lived cache used for local validation; the authoritative permission set lives on the AXON Master.

Fail-closed behavior

If communication with the AXON Master is lost, the bridge applies its configured failure policy. The recommended default for access events is fail-closed (deny) rather than fail-open (allow). In a residential building, a brief inconvenience from a denied call during a Master outage is preferable to opening access during the same outage. The exact policy is configurable per channel because some applications — for example, fire-mode override — must explicitly fail open.

07 — Real-World Deployment Scenarios

1990s residential elevator retrofit in Prishtinë

A 14-floor residential building in Prishtinë was built with a manufacturer-original elevator controller and discrete landing call buttons. The owner wants RFID access to specific floors per resident, without replacing the elevator. AXON PBC-Bridge is installed in the elevator cabinet, wired to the existing landing call signal lines. AXON Nodes are added at each landing with Wiegand-26 readers for RFID. The Master holds the floor-to-credential mapping. The elevator's motor controller, safety circuit, and travel logic are not touched and stay under their existing certification.

Mid-rise office in Tiranë with mixed-tenant floors

A 9-floor office building in Tiranë has a working elevator controller from the early 2010s, but legacy push-buttons in the cabin. The building manages multi-tenant access: some floors are open during business hours, others are restricted at all times. The PBC-Bridge converts cabin button presses into AXON BUS events, the Master applies per-tenant time windows, and the elevator responds only to authorized requests. Tenant changes are handled centrally on the Master with no rewiring.

Hospital with controlled-wing access

In a hospital, certain wings must be reachable only by specific staff classes. The existing elevator controller is kept in place under medical-equipment certification. PBC-Bridge converts call signals from the affected floors into AXON BUS events, the Master applies role-based permissions (medical, administrative, cleaning, family, contractor), and the audit log feeds the hospital's compliance reporting. Visiting-hour changes are a single Master configuration update.

Hotel with staff-only floors

A hotel with two staff-only floors keeps its existing elevator controller and uses PBC-Bridge to route landing calls for those floors through the AXON Master. Guest cards are simply not in the authorized list for the staff floors. The Bridge mode allows the Master to actively gate the call rather than only audit it, which prevents inadvertent guest arrivals on back-of-house floors.

08 — Installation Requirements

• Power: a stable 12 V or 24 V DC source at the elevator cabinet. The exact current budget will be confirmed at release; size the cabinet supply with margin.
• Legacy input wiring: identify the push-button lines and legacy protocol signals to be routed through the bridge before installation. The bridge replaces nothing on the legacy side — it taps in alongside existing wiring.
• Logical isolation of the signal layer must be preserved by the installation: the bridge expects to be the boundary between the legacy electrical world and the AXON BUS. Avoid sharing grounds with high-current motor circuits in the same cabinet.
• AXON BUS cabling: a dedicated twisted pair from the bridge to the rest of the AXON backbone. Avoid running it parallel to motor feed cables or contactor coil lines.
• Enclosure: the cabinet the bridge lives in should be the existing elevator cabinet wherever possible, both to keep wiring short and to keep maintenance access under existing procedures.
• Commissioning: start every retrofit in Converter mode for an initial period of audit-only operation. Confirm the AXON Master sees the events you expect, that timing matches the elevator's existing behavior, and that no phantom events appear from noise. Only then switch to Bridge mode where the Master can actively drive the elevator.

09 — Recommended Topology

The PBC-Bridge is one node on the AXON BUS. The recommended deployment shapes are:

1. Single-cabinet retrofit. One PBC-Bridge in the elevator cabinet, AXON Nodes at one or more landings for RFID, all sharing a single AXON BUS back to the AXON Master in the building services area. This is the common case for a residential or small commercial retrofit.
2. Multi-cabinet retrofit. Larger buildings with multiple elevators get one PBC-Bridge per elevator cabinet. Each bridge has its own address on the AXON BUS; the Master treats them as independent endpoints. This scales without cross-coupling between elevators.
3. Bridge-plus-native hybrid. A building with one legacy elevator and one new elevator can run a PBC-Bridge on the old one and native AXON modules on the new one, all on the same bus and the same Master. The audit log is unified.

Common pitfalls to avoid: do not branch the AXON BUS into a star to reach every device; keep the topology linear with short stubs to each node. Do not share ground between the bridge and the elevator motor circuit. Do not route AXON BUS cabling parallel to mains or contactor coils — the induced noise will eat into the bus error budget exactly as it does on any other industrial bus.

10 — Troubleshooting Guide

Legacy button presses do not produce events on the AXON BUS

Confirm the input channel is correctly wired and configured for the signal type in use. The bridge will reject signals that fall outside its expected envelope — that is a feature, not a bug, because it prevents noise from generating phantom events. Verify with a multimeter that the input actually transitions when the button is pressed.

The AXON Master sees a flood of events for a single button press

Almost always contact bounce on the legacy side that has slipped through the configured debounce window. Confirm the debounce setting matches the actual button hardware in the field; older mechanical buttons in long service often bounce far longer than spec.

In Bridge mode, the elevator does not respond to authorized calls

Check the output side wiring back into the legacy controller and confirm the legacy controller's expected input level matches what the bridge is asserting. Many elevator controllers expect a specific pulse duration or contact closure pattern, not a steady level. The bridge's output configuration must match what the existing controller actually requires.

Events drop out for several seconds at a time

Usually an AXON BUS physical-layer problem: missing or excess termination, a noisy parallel run with motor cabling, or a marginal connector. The bridge participates in the same bus error handling as every other AXON BUS node; persistent bus-off conditions almost always indicate a wiring fault and not a firmware bug.

Master loses contact with the bridge after a contactor switches

Inductive kickback from a contactor coil in the same cabinet is being coupled onto the AXON BUS pair. Snubber the contactor coil at the source, move the bridge to a separate quieter rail, or re-route the bus cabling away from the contactor wiring. This is an electrical-installation issue, not a module issue.

11 — How AXON PBC-Bridge Compares to Alternatives

• Full elevator-controller replacement. Maximally invasive: replaces a working safety-certified controller, re-opens certification, multiplies cost and downtime. PBC-Bridge avoids all of this by sitting alongside the existing controller and only converting the access-relevant signals.
• Generic relay-card retrofits. The common bargain solution is a board with input relays that snap on top of button lines. These usually have no protocol mapping, no audit log, and no central permission concept — they just toggle inputs. PBC-Bridge frames events on a real bus, integrates with a central Master, and produces an auditable trail.
• Per-button local controllers. Putting a small controller behind every button works but explodes the device count, the cabling, and the maintenance overhead. PBC-Bridge consolidates conversion at the elevator cabinet itself, where the signals already converge, and rides a single bus from there.
• IP-per-elevator gateway. Some vendors offer an Ethernet gateway per elevator. Flexible but requires structured cabling to the elevator cabinet, which most retrofit projects do not have. The AXON BUS uses a twisted pair, far cheaper to pull through an existing riser.

12 — Current Implementation Status and Roadmap

What is confirmed today

• Function: convert existing push-button and legacy line signals into AXON BUS communication frames.
• Input: button lines and legacy signals from the existing elevator installation.
• Output: AXON BUS, mapped protocol, integrating with the AXON Master for central or local validation.
• Logical isolation of the signal layer between legacy and AXON sides.
• Mode: Converter (one-way) or Bridge (bidirectional), selectable.
• Power: 12 V DC or 24 V DC.

What is being finalised

• Channel count per board and exact input-signal envelopes for each supported legacy protocol.
• AXON BUS framing parity with the rest of the AXON module family — same addressing model, encryption posture, and error-handling.
• Field-validated compatibility matrix against a representative set of legacy elevator controllers in regional service.
• Production-unit current draw at 12 V and 24 V for cabinet supply sizing.
• Final pinout, terminal layout, and mode-selection mechanism.

What is planned beyond v1

• Expanded library of mapped legacy protocols as field experience grows.
• Per-device keys and authenticated framing on the AXON BUS in line with the rest of the AXON roadmap.
• Diagnostic export so a technician on site can read the bridge's last N events without an AXON Master in the loop.

13 — Key Takeaways

14 — Frequently Asked Questions

What does the PBC-Bridge actually convert?

It samples discrete push-button lines and legacy elevator controller signals on its input side, frames them as AXON BUS messages, and emits them on the output side. In Bridge mode, AXON BUS commands are converted back into legacy-compatible signals that the existing elevator controller already understands. The original controller is not modified.

Why not just replace the elevator controller?

Because replacing a controller is invasive, regulated, and far more expensive than upgrading access control. The bridge keeps the existing motor and safety logic untouched and adds modern access control around it. That preserves certification, reduces downtime, and isolates the project scope to the actual goal.

Does the bridge decide who gets access?

No. The bridge is a converter. The AXON Master holds the permission logic, time windows, and audit log. The bridge can be configured for central validation (every event referred to the Master) or local validation (a short cache for fast paths), but the authoritative state always lives on the Master.

What is the difference between Converter and Bridge modes?

Converter mode is one-way: the module observes legacy signals and reports them to the Master. Bridge mode is bidirectional: the Master can also drive signals back to the legacy controller. Converter mode is typical for an initial audit period; Bridge mode is enabled once the integrator is confident the Master's behavior matches expectations.

Why both 12 V DC and 24 V DC?

Because the regional installed base runs on a mix of both. Accepting either rail lets a single SKU drop into either kind of cabinet without an extra converter.

How does the bridge appear on the AXON BUS?

As a standard AXON BUS node with its own address. The Master treats it the same way it treats any other AXON device, which keeps the Master logic uniform and the audit log consistent across native and retrofit installations.

What happens if the AXON Master is unreachable?

The bridge applies the configured failure policy per channel. The recommended default for access events is fail-closed, because silently allowing access during a comms outage is worse than briefly denying it. Specific channels — for example fire-mode override — are configured to fail open.

Can one bridge handle multiple buttons or signals?

Architecturally yes; the exact channel count per unit is being finalised in development. Larger installations use multiple PBC-Bridge units on the same AXON BUS, each independently addressed.

Is the PBC-Bridge available today?

It is in development. The function and intended behavior are confirmed; final pinout, channel count, supported legacy controllers, and current draw are being finalised through pilots. Anyone planning a retrofit that depends on PBC-Bridge should contact AXON to confirm compatibility with the target elevator controller.

How does the PBC-Bridge interact with AXON Nodes at the landings?

Both report into the same AXON Master and share a single audit log. The Node captures RFID at the landing; the Bridge converts legacy button and signal events. The Master correlates them — for example, an authorized RFID at a landing followed by a call signal on the elevator controller can be treated as a single authorized event.

15 — Related Guides and Products

16 — Plan a Retrofit with AXON PBC-Bridge

Planning a non-invasive elevator access retrofit in Kosovo, Albania, or the wider region? We can review your existing elevator controller, confirm whether PBC-Bridge is the right fit, and scope the AXON topology for your specific cabinet and riser layout. Because the module is currently in development, please contact AXON before committing schedule or budget so we can align on availability and confirm compatibility with the legacy controller in question.

References and Standards

• EN 81-20 — Safety rules for the construction and installation of lifts (passenger and goods passenger lifts)
• EN 81-50 — Examinations and tests of lift components
• TIA-485-A — Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems (RS-485)
• IEC 60747-5-5 — Semiconductor devices: Optoelectronic devices, photocouplers