AccessCORE PACS Studio

The PACS overview brings together, for the site chosen in the header, controller connectivity, sync status, and faults on I/O modules and readers. The health of the whole installation can be checked before opening a single detail screen.

Selecting a connection state filters the controller list below, and I/O faults are counted separately as offline modules, AC power faults, battery faults, tamper, and offline readers. The figures update in real time, and live updates can be paused while investigating.

Items that need action, such as access points without an access area or controllers that have not yet received their full configuration, are listed with counts. Each one opens the matching list already filtered, so installers can work through what remains.

A cardholder is a person the access control system recognizes. Employees are registered and issued credentials such as cards, PINs, or licence plates, and each person’s organization, access start and end dates, access levels, and leave period are kept together.

A cardholder is active, pending, or suspended, or on leave or expired according to dates, and anyone not active has their cards treated as unusable. Special privileges such as anti-passback exemption, extended door open time, and PIN exemption are set per person.

A card number is issued to only one person across the system. Suspending a cardholder revokes all of their cards and removes them from the controllers at the next sync. Cardholder groups only organize people; door access comes from access levels alone.

Changes saved in the console are not sent straight to devices; they wait in a delivery queue until an installer runs a sync, while changes that must take effect at once, such as visitor check-in, start a sync automatically. The dashboard shows pending changes, skipped controllers, failed syncs, and the result of the last run.

The sync plan separates items shared by every site from items for the selected site only. Cardholders, access levels, schedules, card formats, and LED presets reach every controller in a single run, while controller and access point settings go out only for their own site.

A controller that needs a reset, or whose deliveries are blocked after rejected data, is left out of sync runs. Once the cause is fixed, a Full Download resends its whole configuration from scratch, settles the changes queued in the meantime, and brings the device and the server back in line.

The current state of the selected site’s controllers, access areas, access points, and monitor point groups is shown on separate tabs: door alarms and contact faults, occupancy and capacity breaches per area, and when each controller last responded.

Operators with monitoring control permission can open a door remotely, switch how it admits people, such as card only or card and PIN, and arm or disarm monitor point groups. After a command is sent, the screen shows whether each controller received it.

The screen loads the current state once and then receives every change pushed by the server, so it never needs refreshing. When a value looks doubtful, the devices can be asked for their state again and the table is refreshed with the answer.

A message broker and middleware sit between the server and the field devices. The server sends configuration changes, control commands, and status queries as messages; the middleware drives the HID Aero controllers through the vendor SDK and returns results, events, and status reports the same way.

Each change is written to the delivery queue in the same transaction that saves it, so nothing is saved without also being queued for delivery. Deliveries are ordered by the dependencies between settings, and an item created and deleted within the same batch cancels out and is never sent.

Commands, results, events, and status reports travel on separate channels. Deliveries that fail on a connection error are retried by the system, while a controller that rejects data has its following deliveries held until a Full Download realigns its whole configuration.