Physical Access Control Systems (PACS) Architecture and Components
This domain tests the signal path and division of labor in a PACS: credential, reader, controller, door hardware, head end, network, and power. You should know what makes an access decision, what happens when the server is offline, and where architecture weak points sit.
Architecture
- The credential presents identity data.
- The reader converts the credential into a format such as Wiegand, OSDP, or IP and sends it to a controller.
- The controller holds door groups, schedules, and permissions. It decides grant or deny, energizes the lock output, monitors door status, and records events.
- Door hardware executes the decision: lock, strike, request-to-exit sensor, and door position switch.
- The head end manages badges, rules, reports, and integrations with video, fire alarm, and intrusion systems.
- Power supplies and network links are supporting subsystems that can become single points of failure.
Distributed intelligence
Modern panels make decisions at the controller, so doors continue to work if the head end is offline. Events buffer locally and synchronize later. If the controller itself fails, the door behaves according to the lock's fail-safe or fail-secure design.
Worked example
An employee badges at an interior door. The reader reads a MIFARE identifier; the controller checks the schedule and access level, grants access, releases the strike for five seconds, monitors the door position switch for held or forced conditions, and logs the event. If the network is down, the controller still decides from its local database. If the controller is down, the lock type determines whether the door unlocks or stays secure.
Traps
Do not say the reader grants access; the controller does. Do not assume a server outage stops all doors. Do not ignore controller capacity, power, or network dependency. Do not confuse Wiegand wiring with a secure protocol.