Services
Programming and System Configuration
Controller programming, access levels, card formats, event logic, alarm behaviour and retention settings, configured deliberately and written down so the next technician is not guessing.
The pattern
Most reported hardware faults are configuration faults
A door that does not work looks like a broken door. In the majority of the access control calls we take, nothing is broken.
The reported symptom is physical, so the response is physical. A reader gets swapped. Then a lock. Then a controller board. The fault survives all three, because the reader was reading correctly the whole time and the credential was being denied by a rule.
This is not carelessness. A door that denies a valid badge produces exactly the same complaint whether the cause is a failed reader, a card format mismatch, a schedule that expired, a door that was never added to the access level, an anti-passback state, or a controller holding stale data from a download that failed months ago. Distinguishing between them means reading the event log and the configuration, not testing continuity.
The diagnostic order we use is simple and it is the reason parts stop getting replaced. Present the credential and read what the system recorded. A denial with a reason is a configuration answer. A read with the wrong bit count is a format answer. No event at all is a communication or wiring answer, and only then does hardware enter the picture. Most calls resolve in the first two.
The same logic applies on the video side. Cameras reported as failing are often recording exactly as configured, on a schedule or motion rule that nobody has looked at since commissioning.
What programming work covers
Configuration work on an enterprise platform is structured. These are the layers, roughly in the order a fault is traced through them.
Controller programming
The panel level, where doors, readers and inputs are actually defined.
- Controller and door module configuration on enterprise platforms including iSTAR and comparable controllers
- Reader configuration, including OSDP and Wiegand parameters, addressing and supervision
- Door behaviour: strike time, held-open and forced-door timing, request-to-exit handling, door contact logic
- Offline and degraded-mode behaviour, so a controller that loses the server still enforces something sensible
- Firmware level checked against the server version, since a mismatched controller can accept a download and ignore parts of it
- Download and memory verification, confirming the controller holds what the database thinks it holds
Access levels and schedules
The rules that decide who opens what and when. This is where most denials originate.
- Access level design built around roles and areas rather than individual doors added one at a time
- Time schedules, holiday tables and the interaction between them, which is a routine source of long-weekend failures
- Door groups and area definitions so a new door is added in one place instead of forty
- Temporary, contractor and visitor access with automatic expiry rather than a manual cleanup that never happens
- Anti-passback, occupancy and interlock rules where the facility requires them
- Review of existing levels for overlap, contradiction and privileges that were meant to be temporary
Credentials and card formats
Format configuration is invisible until a new batch of cards arrives and half the population cannot get in.
- Card format definition, including bit length, facility code, parity and site code handling
- Multiple concurrent formats where a site is midway through a credential change
- Diagnosis of raw read data when a badge produces an unknown-format or invalid event
- Mobile credential and multi-technology reader configuration
- Cardholder import and synchronization from HR or directory sources, including field mapping and de-duplication
- Credential lifecycle rules: issue, reissue, lost-card handling and automatic deactivation on termination
Inputs, outputs and event logic
The part of the system that makes something happen when something else happens.
- Input point configuration, supervision and end-of-line settings
- Output and relay control, including elevator, gate, barrier and mantrap sequences
- Event-triggered actions linking access control events to video, notification or door state changes
- Lockdown and emergency procedures, with a defined and tested way to release them
- Suppression of nuisance events so real alarms are not buried under noise
- Verification that each configured action fires in the field, not only in the software
Alarm and monitoring configuration
An alarm nobody responds to is worse than no alarm, because it trains operators to ignore the screen.
- Alarm priority, colour, sound and acknowledgement requirements set so priority means something
- Routing by area, time of day and operator group
- Instruction text attached to alarms so the operator sees the procedure with the event
- Escalation and unacknowledged-alarm behaviour
- Email and notification delivery, tested end to end rather than assumed
- Nuisance alarm reduction, which is usually the highest-value hour of the engagement
Video recording and retention settings
Recording configuration decides whether the footage exists when it is finally needed.
- Recording schedules, continuous and motion-based rules, and pre and post-event buffers
- Resolution, frame rate and stream configuration balanced against storage and network capacity
- Retention set to the site policy and then verified against what the recorder is actually keeping
- Motion detection zones and sensitivity tuned to stop weather, headlights and foliage from filling storage
- Camera-to-door and camera-to-alarm associations so an event opens the right footage
- Export, watermarking and evidence-handling settings agreed with whoever produces footage for investigations
Operator accounts and permissions
Who can see, change, unlock and export. Usually the least maintained part of a mature system.
- Operator privilege design by role, with partitioning where separate departments share one system
- Active Directory group mapping and single sign-on where the site uses it
- Restriction of high-consequence functions such as remote unlock, lockdown and configuration edits
- Audit trail configuration so configuration changes are attributable to a named operator
- Cleanup of accounts belonging to people and contractors who have left
Maps and monitoring interfaces
The screen an operator works from. Layout is an operational control, not decoration.
- Site, floor and area maps with devices placed and live status shown
- Alarm and event view layout so the important column is not the one scrolled off screen
- Monitoring workstation and video wall configuration
- Standard views and default layouts so a relief operator is not reconfiguring at shift start
- Reports and scheduled outputs for audit, muster and access review purposes
Testing, commissioning and documentation
Configuration is not finished when it is entered. It is finished when it has been proven and recorded.
- Door-by-door functional testing with valid, invalid, expired and out-of-schedule credentials
- Alarm and event verification from the field device through to the operator screen
- Video verification: recording present, retention correct, associated camera opens on the event
- Failure-mode testing including communication loss and power loss where the site permits it
- A written configuration record: naming conventions, access level structure, schedules, formats, integration points and known exceptions
- Handover walkthrough with the security team so the people who use it understand what changed
Reported symptom against actual cause
Drawn from the calls we take most often. The right-hand column is what the fault usually turns out to be once the event log has been read.
| Symptom | Commonly reported as | What it usually is |
|---|---|---|
| Badge works at some doors, not others | Failed reader at the affected door | The door is not in the access level, or sits in a door group the level does not include |
| Access denied only in the evening or on a holiday | Intermittent controller fault | Schedule boundary or a holiday table applying a different rule than expected |
| New cards do not work, old cards do | Bad card batch | Card format mismatch: different bit length or facility code from the batch the system was configured for |
| Door unlocks but alarms as forced | Faulty door contact | Strike time and contact logic mismatched, or request-to-exit not shunting the point |
| Operators ignore the alarm screen | Operator training issue | Every alarm set to the same priority, with nuisance points never suppressed |
| Footage missing for the day requested | Recorder failure or disk fault | Retention shorter than believed, or a schedule and motion rule that was never recording that view |
| A change was made and nobody knows by whom | System instability | Shared operator accounts and audit trail not configured |
Hardware does fail, and when it has we say so and replace it. The point is the order of investigation, not a claim that parts never break.
Optimization
Cleaning up a system that has been running for a decade
Configuration accumulates. Every temporary exception, every one-off door addition, every departed administrator leaves a trace, and after enough years nobody can safely change anything.
The recognizable state is a system with several hundred access levels for a few dozen actual roles, schedules named after people who left, door groups that overlap in ways nobody has mapped, and an unwritten rule that certain configuration must not be touched because the last person who tried broke a door.
Cleanup is done by analysis first, not by deleting. We export the current configuration and produce a picture of what exists: which levels are assigned to nobody, which duplicate each other exactly, which schedules are unreferenced, which doors appear in levels that no longer match their department, and which cardholders hold privileges that no current role justifies.
That picture goes to the security manager as a proposal, because deciding who should have access is the facility’s decision, not the technician’s. Once a target structure is agreed, changes are staged. Consolidate levels first, verify against a sample population, then retire the old ones after a defined observation period rather than deleting them the same afternoon. Retiring an access level that turns out to be in use during a night shift is the failure mode this sequence exists to prevent.
The outcome is a structure a new administrator can read, plus a written record of the naming convention and the intent behind it. That record is the difference between a system that stays clean and one that is back in the same state in three years.
When it comes up
Situations that call for programming work
- A department moved floors. Access levels, door groups and schedules need to follow the people, and the old privileges need to come off.
- A credential change is underway. New cards are being issued while the old population is still active, and both formats have to work during the transition.
- An audit is coming. Somebody has to produce who has access to what, and the current structure cannot answer the question cleanly.
- The alarm screen is ignored. Nuisance events have trained operators to acknowledge without reading.
- New doors were installed by a contractor. The hardware is in and wired, and nothing has been programmed, tested or added to the right levels.
- A lockdown procedure exists on paper only. Nobody has configured it, tested it, or established how it gets released.
- Video is recording but not usefully. Retention is short, motion detection triggers on nothing, and cameras are not associated with the doors they cover.
- The system was inherited. No documentation, no naming convention, and every change carries the risk of breaking something undocumented.
- Turnover in the security office. The administrator who knew the system has left and nobody was trained.
How configuration changes are handled
Configuration on a live security system is changed under agreed change control. Before work begins we take a database or configuration backup, agree what is being changed and in what window, and confirm who authorizes access decisions on the client side. Access rights are the facility’s decision. We implement what the security manager approves and record it.
Programming work does not include new cabling, drilling, conduit or device installation. Where a fault turns out to be physical, we identify it precisely, and remediation falls under access control service and repair or system restoration.
Every engagement ends with a written record of what was changed. If we are not the ones who return next time, the next technician should be able to work from the document rather than reverse-engineering the system.
Common questions
Why does a badge work on one door and not the next one?
Almost always because the second door is not in the access level assigned to that cardholder, or it is in a door group the level does not include. This happens most often after a door is added, renovated or renumbered: the door exists, it is wired and communicating, and it was simply never added to the levels that should contain it.
The next most common causes are a schedule difference, where the two doors are governed by different time schedules and one has already closed for the evening; an area or partition rule such as anti-passback, where the system believes the person is already inside; and a controller holding stale data, where the level was updated in the database but the download to that specific panel did not complete.
All four are visible in the event log. The event will name the reason for the denial. If instead there is no event at all when the badge is presented, the question changes from configuration to communication, and that is where hardware investigation starts. Reaching for a reader before reading the log is what turns a fifteen-minute fix into three service calls.
We have years of accumulated access levels. Can that be cleaned up without breaking access?
Yes, but not by deleting in bulk. The safe sequence starts with analysis: export the current configuration, identify levels assigned to no active cardholder, levels that are exact duplicates of one another, schedules nothing references, and doors that appear in levels inconsistent with their current department.
That analysis becomes a proposal for a smaller set of role-based levels. The security manager decides what each role should actually reach, because that is a facility decision and not a technical one. We then build the new structure alongside the old, move a representative sample of cardholders, and observe.
Old levels are retired rather than deleted, after an observation period long enough to cover every shift pattern, weekends and any monthly activity. That period is what catches the level nobody remembered was used by night cleaning staff or a quarterly contractor. The work is staged over sessions rather than done in one pass, and each stage is reversible until it is confirmed.
We changed credential suppliers and now some cards fail. What causes that?
A card format mismatch. Credentials encode data in a specific bit structure, with a facility or site code and parity arrangement. The system is configured to expect particular formats. A new batch ordered with a different bit length, a different facility code, or from a different encoding programme will be read correctly by the reader and rejected by the system as unknown or invalid.
The diagnosis is direct. Present a failing card and look at the raw read in the event log. It will show the bit count and the data received, which identifies the actual format of the new batch. That is compared with what the system is configured to accept.
The fix is to define the new format in the system, alongside the existing one. Running two formats concurrently is normal during a credential transition and is the correct approach while a population is being reissued over months. The second format is removed only once the old cards are confirmed out of circulation. It is also worth checking multi-technology readers, which may need their own configuration to read the new technology at all.
Can programming be done remotely, or does it need a site visit?
A large share of configuration work can be done remotely where the client permits secure access. Access levels, schedules, cardholder structure, operator permissions, alarm priorities and routing, report configuration, retention settings and most database-side work do not require anyone to be standing at a door.
What requires attendance is anything that has to be verified physically. Functional door testing with real credentials, reader and lock behaviour, input point supervision, verifying a relay actually fires the gate, controller work needing physical access, and final commissioning. A configuration change that has not been tested in the field is not finished, and video verification of a door test is a partial substitute at best.
The usual arrangement is a mix. Preparation, analysis and the bulk of the configuration are done remotely, then a site visit covers testing and the items that need hands on the equipment. That keeps the on-site time short and focused. Remote access is always established on the client’s terms, through whatever method their IT department approves, and detail on ongoing arrangements is covered under ongoing technical support.
How do you document configuration so the next technician is not guessing?
By writing down the intent, not just the settings. A configuration export lists what exists. It does not say why an access level is structured the way it is, why one door has a longer strike time, or which schedule serves which department. The reasoning is what disappears when a person leaves.
What we hand over is a written record covering the naming convention and what each part of a name means, the access level structure mapped to roles and areas, schedules and holiday behaviour, card formats in use and the state of any credential transition, input and output logic including anything non-obvious, alarm priorities and routing rules, integration points with video, intercom, elevator and other systems, and a list of known exceptions with the reason each one exists.
The exception list is the most valuable page. Every mature system has settings that look wrong and are deliberate. Recording them stops the next technician from correcting something that was configured that way for a reason.
Can you work on a system another company installed?
Yes. That is most of what we do. We are a service company and not a product vendor, so there is no requirement that we installed the system or that you buy anything from us to have it worked on.
What we need at the start is administrative access to the software, the version numbers of the server and clients, and whatever documentation exists even if it is incomplete. Where nothing exists, the first engagement includes producing a baseline record of the current configuration, which is useful in itself.
We do not disparage the original installer, and we do not use a service call to sell a replacement system. If the existing platform is sound and misconfigured, we say so and configure it. See systems we support for the platforms we work on.
Before the next part gets replaced, read the event log
Describe the symptom and the platform you are running. We will tell you whether it reads as configuration or hardware.