Features · Access control
Design the doors on the same model as everything else.
Readers, locks, REX, door position, controllers and their power — placed on the real floor plan, wired with protocol-correct cable runs, and carried into a door schedule that cannot drift from the drawing it came from.
One opening, end to end
- 01 Door handing, fire rating, ADA state, dimensions
- 02 Reader technology, mount height, comm protocol
- 03 Lock strike or maglock, 12 or 24 VDC, fail mode
- 04 DPS / contact supervised, end-of-line resistor value
- 05 REX request-to-exit, checked against egress rules
- 06 Controller port assignment, capacity from the datasheet
- 07 Power supply load-summed, battery sized to UL 294
- 08 Back to the closet cable type, real length, MDF or IDF
The opening
A door is a door, not a dot
Most tools let you drop an access icon on a plan. Here the opening itself is modelled — handing, fire rating, ADA state, dimensions and hardware — so the design can reason about it. That is what makes an egress conflict findable before an inspector finds it.
- Eleven access device types: reader, controller, strike, maglock, REX, door position, intercom, turnstile, biometric, motion, and door hardware.
- Each device carries its real configuration — Wiegand, OSDP or IP, 12 or 24 VDC lock power, fail-safe or fail-secure, supervised end-of-line resistance.
- Doors found on the uploaded drawing are proposed for confirmation, never written silently — and every door records where its identity came from.
- The door and the access hardware are reconciled against each other: a lock type that disagrees with the device linked to it is a finding, not a footnote.
Door schedules
Import the architect’s schedule. Publish one that matches.
The door schedule is where access-control jobs usually come apart: the architect has one, the drawing has another, and the field has a third. Here they are the same record, resolved through one canonical label.
- Hardware schedules import from XLSX or CSV, with columns auto-mapped and values normalised into the model.
- Each imported row is matched to a real opening on the plan, scoped to the floor so a level-2 door cannot match a level-1 one.
- One canonical label per opening (ADR-026), carrying its provenance — architect import, drawing detection, or manual entry.
- The same schedule publishes into the plan set, the access-control submittal, the field report and the as-built — not four exports that disagree.
What a published door row carries
- Door number
- canonical, provenance-stamped
- Hardware
- lock type, fail mode
- Power
- lock voltage and current draw
- Monitoring
- DPS and REX present or absent
- Credential
- reader technology
- Paired camera
- the camera covering the opening
One row, one truth — the plan set, the submittal and the field package read it from the same place.
Controllers & power
Capacity from the datasheet — or an honest blank
Port counts and power are where access designs quietly go wrong. The platform reads capacity from the controller you actually specified, and when the library does not carry a number, it says so rather than assuming one.
- Reader-port count and door capacity come from the product-library entry for that controller. No number in the library means the platform reports it unknown — it never substitutes a default.
- A controller whose capacity data contradicts itself is flagged rather than silently averaged.
- Power supplies are sized from summed real load — 500 mA per 12 V lock, 300 mA per 24 V lock, plus sensors — onto standard supply ratings with headroom.
- Battery backup is sized to UL 294, and PoE-powered access hardware is resolved through the same single power resolver the rest of the platform uses.
Cable runs
Protocol limits, checked against the real pull
A reader 700 feet from its controller on Wiegand is a truck roll waiting to happen. Runs here are measured on the plan at true scale — routed, not drawn straight — with the vertical rise, a service loop and slack included, then checked against the protocol you chose.
- Wiegand is held to 500 feet, OSDP over RS-485 to 4,000 feet, and IP devices to the structured-cabling limit.
- Readers default to a 48-inch mount height for ADA reach, and the run is measured from where the device actually is.
- Access runs join the same cabling and closet plane as cameras, wireless and everything else — one cable schedule, one closet, one set of counts.
- Every run lands on a real MDF or IDF, so the door count and the closet capacity are the same conversation.
What you hand over
An access-control submittal, generated from the design
The design is the document. The access-control package is produced from the same model that computed it, so a change to a door is a change to the submittal.
- Door, reader, intercom and controller schedules, plus a per-controller port matrix.
- A per-controller wiring topology — controller to port to cable to reader to door.
- Power-supply and battery sizing with the load it was derived from.
- Project-level compliance checks on the submittal — protocol distances, controller loading and egress fail-mode — alongside the per-opening findings the design surfaces as you work.
- Floor maps with the access devices overlaid, and the T-600 door schedule inside the multi-floor plan set.
- A mobile access-control report for the technician standing at the door.
Access control, on the same record as the rest of the job
- 11
- access device types
- reader, controller, strike, maglock, REX, DPS, intercom, turnstile, biometric, motion, door hardware
- 500 / 4000 ft
- Wiegand / OSDP limits
- checked against the real run length
- UL 294
- battery backup sizing
- from summed lock and device current
- ADR-026
- one canonical door label
- architect import, drawing detection, or manual — one answer
Frequently asked questions
Can it import our architect’s door schedule?
Yes. Door hardware schedules import from XLSX or CSV, columns are auto-mapped, values are normalised, and each row is matched to the door opening on the floor plan — floor-scoped, so a door on level 2 cannot silently match one on level 1. Import alone never invents a value — what the schedule does not say stays empty. There is a separate, optional normalisation pass that will infer conventional defaults for unstated fields such as fail mode or egress status; it is stamped on the row when used, and it is a step you choose, not something the import does behind you.
How are doors numbered?
One canonical label per opening, resolved through a single function so the plan set, the door schedule, the field report and the as-built cannot disagree. Labels come from the architect’s import, from detection on the drawing, or from manual entry, and every label carries which of those it came from. Formats follow the common conventions (D-101, D-G01, D-B201, D-101A).
Does it check egress and life safety?
It flags, it does not certify. A maglock without a request-to-exit device on an egress door is raised as a life-safety conflict, fail-secure hardware on an egress opening is warned, and a mismatch between the door’s recorded lock type and the linked access device is reconciled rather than ignored. Fire, ADA and access-control rule packs run against the opening. A licensed professional still signs the design.
How does it know a controller is full?
Controller capacity is read from the product library entry for the controller you actually specified — its reader-port count and door capacity. If the library does not carry that number, the platform reports it as unknown and refuses to invent one; a controller with contradictory capacity data is flagged rather than averaged. Port assignments are made against real capacity, not a guess.
Are the cable runs real lengths or straight lines?
Real runs. Each pull is measured on the plan at its true scale, routed rather than drawn point-to-point, plus the vertical rise, a service loop and slack — then checked against the protocol limit for the cable you chose: 500 feet for Wiegand, 4,000 feet for OSDP over RS-485, and the structured-cabling limit for IP devices. A run that exceeds its protocol is flagged at design time.
What does it not do?
It does not manage credentials or badges, it does not place readers for you, and it does not model door throughput or queueing — that engine exists but is not wired to a design surface, so we do not sell it. There is no dedicated multi-floor access riser drawing; access runs appear in the cabling and closet plane with everything else. It is a design and documentation platform, not an access-control head end.
Put your doors on the model
Bring a floor plan and a door schedule — we will import it, match it to the openings, and show you the submittal that comes out. Talk to us about what your team needs.