An enterprise access-control system almost never fails in one event. It degrades over several years, and every stage of that degradation produces a symptom that somebody notices and works around.
The workaround is the problem. A reader that needs two presentations gets two presentations. A door that alarms every morning gets its alarm acknowledged every morning. A panel that goes offline for ninety seconds at 04:00 goes unnoticed because nobody reads the audit log at 04:00. By the time the failure is unavoidable, the system has been telling you about it for eighteen months.
Preventive maintenance is the practice of reading those signals on purpose. What follows is what to look for, and what each signal usually means.
Indicators that show up in the software
These cost nothing to check. Most access-control platforms will report all of them, and the reports are usually never run.
Communication-loss events, clustered
Pull every controller offline and online event for the last ninety days and sort by time of day, not by count.
- A cluster at a fixed hour points at a scheduled load: HVAC starting, a generator test, a UPS self-transfer, a cleaning crew unplugging something.
- A cluster on one branch of an RS-485 loop points at the loop, not at the panels.
- Events scattered evenly with no pattern usually point at power or a marginal connection rather than at the network.
Download and sync duration
Time a full download to a controller and compare it against a controller of the same model on a different loop.
- A download that used to take four minutes and now takes twenty is either a larger cardholder set or a link that is retrying.
- Retries do not always report as failures. They report as slowness.
- Controllers that fall out of sync and self-correct are logging the retry somewhere. Find that counter.
Door alarm volume
Count door-forced and door-held events per door per month and rank them.
- The top three doors are almost always mechanical: a misaligned strike, a sagging closer, a magnet gap that has opened up.
- A door that has moved from twenty events a month to two hundred has a hardware fault, not a behaviour problem.
- A door with zero events in a year on a busy corridor is more suspicious than one with many.
Database and event history growth
Check the size of the event or journal database and its growth rate, then compare that against free space on the volume.
- Event history grows with cardholder count and door count and never shrinks unless somebody purges or archives it.
- A system on SQL Server Express hits a hard database size ceiling and stops writing history rather than warning gracefully.
- Report generation slowing down is often the first visible symptom of an unmaintained journal.
Indicators that only show up at the door
Software tells you about behaviour. It does not tell you about condition. The following require somebody at the door with a meter.
Read range shrinking. A reader that used to present at three inches and now needs contact is usually not a failing reader. It is more often a supply voltage that has sagged at the end of a long run, or a reader mounted on metal that has had something else installed nearby. Measure voltage at the reader under load, not at the power supply.
Standby batteries by date, not by voltage. A sealed lead-acid battery holds float voltage almost to the end of its life. A four-year-old battery reading 13.6 V on the charger can still collapse to nothing within a minute under a real load. Batteries need to be load-tested or replaced on age. Voltage alone tells you very little.
Power supplies running near their limit. A supply sized for the original door count and then asked to carry two more magnetic locks will hold on a normal day and sag when every lock is energized at once. The symptom is a panel that cold-starts occasionally and a reader at the far end that behaves oddly at shift change.
Enclosure and environment. Panels in unconditioned closets, in elevator machine rooms next to variable-frequency drives, or in plant areas with airborne dust do not fail immediately. They fail early. Corrosion on terminal blocks and dust bridging on boards are visible on a walk-through and invisible from a workstation.
The supervision that is not supervising
A supervised input reports four states: normal, alarm, open circuit and short. It can only do that because an end-of-line resistor of a known value sits at the far end of the loop, at the device, so the panel can measure the loop rather than just sense continuity.
When a contact is replaced under time pressure and the resistor is left out, or the loop is jumpered at the panel to clear a nuisance trouble, the input still reports normal and alarm correctly. It simply stops reporting cut, shorted or removed. It will read normal forever, including when the field wiring has been cut. Nothing in the software indicates a problem, because from the panel side there is no problem.
This is the single most common finding on a first maintenance visit to an inherited system, and it is only findable by measuring the loop at the panel and comparing it against the expected resistance for that input type. It is a good argument for having someone open the enclosures on a schedule.
A reasonable order to work through it
If you are trying to decide whether a system needs attention before committing budget, this sequence gets you an answer in a day or two of effort.
- 01 Pull ninety days of controller offline events — Sort by time of day and by loop. Patterns here direct everything that follows.
- 02 Rank doors by alarm count — The top ten doors by forced and held events are your mechanical work list.
- 03 Check database size against free space — Record the growth rate. Project the date the volume fills. This number is usually a surprise.
- 04 Establish battery ages — If no date is written on the battery, it is old. Assume replacement is due.
- 05 Open a sample of enclosures — Ten per cent, chosen across different areas and installation dates, is enough to characterize the rest.
- 06 Verify supervision on a sample of inputs — Measure loop resistance and compare against expected values. One jumpered input justifies checking all of them.
- 07 Test the alarm path end to end — Trigger a real condition and confirm it arrives where somebody will see it. A working detector and a broken notification path is a system that does nothing.
What the findings usually justify
Nearly every one of these findings is inexpensive to correct and expensive to ignore. Batteries, terminal cleaning, strike and closer adjustment, resistor replacement and a database maintenance plan are small pieces of work. The failures they prevent are after-hours callouts, and after-hours callouts on a door that will not release are not scheduled around your operations.
If several of these indicators are present at once, the underlying question is usually whether the system is worth maintaining at all. That is a separate decision, covered in repairing versus replacing a security system. If the offline events dominate the findings, start instead with common causes of offline access-control panels.
Get a baseline on the system you have
A preventive maintenance assessment establishes condition, supervision integrity and the work list, in writing.