Integration, programming and user training

By the time the Juniper Point devices are mounted and powered, the three systems each work on their own: the intrusion panel arms and reports, the doors open for valid fobs, and the cameras record. What the board paid for, though, is a system that works together. A forced garage door should raise an alarm at the concierge desk, show the nearest camera and mark the recording. Arming the locker partition at midnight should lock the locker room doors. The lobby intercom should release the door and log who let the visitor in. And the people who run the building should be able to do all this without calling Cobalt Line. This lesson covers how the systems are linked, the cause-and-effect matrix that defines those links, the programming that carries them out, protecting the systems themselves, and how the installer trains the owner's staff.

Ways the systems connect

Security systems connect in three ways. The simplest is hard-wired: a relay output on one system wired to an input on another, such as the access controller's forced-door output wired to an intrusion zone. It is reliable, easy to understand and keeps working if the network fails, but every link needs a pair of wires and a spare input and output. The second is software integration: the video management system and the access control software talk to each other over the network through a supported interface, so an access event can call up a camera and bookmark the recording. It is flexible and needs no extra wiring, but depends on both systems' versions being compatible and on the network. The third is a unified platform, in which one manufacturer's software runs access, video and sometimes intrusion together. Juniper Point uses a mix: hard-wired links for anything that must work during a network failure, and software integration for the camera and event links.

Some links are not the security installer's to make. Fire alarm release of locks goes only through the fire alarm contractor's relay, as lessons 7 and 10 described. Elevator controls, such as restricting floors to residents, go through the elevator contractor's interface. Building automation links, such as turning on garage lights when the gate opens, go through the controls contractor. In each case the installer wires to the interface point the other trade provides, shown on the drawings, and the two trades test the link together.

The cause-and-effect matrix

Every link between systems is written down before it is programmed, in a cause-and-effect matrix, also called a sequence of operations. Each row is a cause, an event in one system; each column is an effect, an action in this or another system; and a mark in a cell means that cause produces that effect. The matrix is drawn up by the designer with the owner, reviewed by each trade involved, and becomes the test document: commissioning tests every marked cell, and the test sheet records the result. Anything not in the matrix is not programmed, however useful it might seem on site.

# Check a cause-and-effect matrix against the commissioning test results
matrix = {
    "garage door forced": ["concierge alert", "camera popup", "bookmark", "station report if armed"],
    "door held 30 s": ["local sounder", "concierge alert"],
    "locker partition armed": ["locker doors locked"],
    "locker intrusion alarm": ["station report", "cameras full rate", "concierge alert"],
    "intercom release": ["lobby unlock 5 s", "event logged"],
    "fire alarm": ["exit locks released", "gates open", "event logged"],
}
results = {  # (cause, effect): passed?
    ("garage door forced", "camera popup"): True, ("garage door forced", "bookmark"): True,
    ("garage door forced", "concierge alert"): True, ("garage door forced", "station report if armed"): False,
    ("door held 30 s", "local sounder"): True, ("door held 30 s", "concierge alert"): True,
    ("locker partition armed", "locker doors locked"): True,
    ("locker intrusion alarm", "station report"): True, ("locker intrusion alarm", "cameras full rate"): True,
    ("intercom release", "lobby unlock 5 s"): True, ("intercom release", "event logged"): True,
    ("fire alarm", "exit locks released"): True, ("fire alarm", "gates open"): True,
}
total = sum(len(v) for v in matrix.values())
passed = sum(1 for v in results.values() if v)
print(f"{total} links in the matrix, {len(results)} tested, {passed} passed")
for cause, effects in matrix.items():
    for e in effects:
        r = results.get((cause, e))
        if r is None: print(f"  not tested: {cause} -> {e}")
        elif not r: print(f"  FAILED:     {cause} -> {e}")

15 links in the matrix, 13 tested, 12 passed
  FAILED:     garage door forced -> station report if armed
  not tested: locker intrusion alarm -> concierge alert
  not tested: fire alarm -> event logged

The check shows one failure, the forced garage door that should report to the monitoring station when the locker partition is armed, and one link not yet tested, the fire alarm event log. Both are fixed and retested before the matrix is signed. A matrix with untested cells is not a commissioned system.

Programming the access system

Programming the access control system is done mostly in its software, from documents the owner has approved. The installer creates the doors, with their names matching the drawings and the signs; sets each door's unlock time, held time, request-to-exit behaviour and schedules from the door schedule, as lesson 6 described; creates the schedules and holidays the owner gave; creates the access levels in the specification; and sets up the alarm and event handling, such as which events appear at the concierge desk and which need acknowledgment. The owner's administrator then enrols people, often from a spreadsheet imported in bulk. The installer sets up the import, checks a sample, and leaves the decisions about who gets what to the administrator.

Holidays and schedule exceptions are a common source of trouble. A school that unlocks its front doors at 7:30 every weekday must not do so on statutory holidays, professional development days or snow days. The access software has holiday schedules and first-person-in rules for exactly this, and the installer programs the year's holidays the owner provides and shows the administrator how to add more.

Programming the video system

In the video management system, the installer arranges cameras into the groups and views the owner uses: the concierge's lobby and garage wall, the property manager's full list, the security team's alarm view. Events from the access system are linked to cameras: each door is associated with the camera or cameras that see it, so that a door event in the access log can be clicked to play the video from that moment. Alarm-triggered recording changes, such as full frame rate during an intrusion alarm, are set from the matrix. User roles in the VMS follow the owner's policy on who may view live, who may play back and who may export, as lesson 9 described.

Protecting the systems themselves

Security systems are networked computers, and LVT-220's security habits apply to every one of them. Change every default password on every camera, controller, recorder and panel at installation. Use the owner's accounts and naming, not the installer's. Update firmware to the version the manufacturer recommends at commissioning, and record it. Put the security devices on their own VLANs, as the owner's network team designs. Turn off services the system does not use, such as unencrypted web access, older protocols and, for cameras, cloud connections the owner has not approved. Make sure OSDP secure channel is on and old credential formats are off. Hand every administrator credential to the owner's named contact in a sealed record, and remove the installer's temporary accounts at handover.

These steps protect the owner and the people in the building. A camera left with a default password can be viewed by anyone who finds it; an access controller with old firmware may have known weaknesses the manufacturer has fixed. The installer is the last person to touch every device before the owner takes it over, and the habits at that moment decide much of the system's security for years.

Training the owner's staff

A security system is only as good as the people who run it. Training is part of the contract, and it is planned like any other part of the job: who needs to know what, how long it takes, and what they will be able to do afterward. The concierge needs to answer alarms, call up cameras, release the lobby door for visitors and know what to do when something fails. The property manager needs to add and remove residents, change schedules, run reports and export video. The board's administrator needs everything, including user roles and backups. Residents need a one-page guide to their fob and the intercom.

# Training plan: who needs which modules, and the total time
modules = {  # module: hours
    "alarm handling and the concierge view": 1.5, "visitor and intercom procedures": 0.5,
    "cardholders, access levels and schedules": 2.0, "reports and audit logs": 1.0,
    "video playback and export": 1.0, "user roles, backups and firmware": 1.5,
    "intrusion arming, codes and troubles": 1.0, "what to do when something fails": 0.5,
}
people = {  # role: (number of people, modules)
    "concierge": (4, ["alarm handling and the concierge view", "visitor and intercom procedures",
                      "intrusion arming, codes and troubles", "what to do when something fails"]),
    "property manager": (2, ["cardholders, access levels and schedules", "reports and audit logs",
                             "video playback and export", "intrusion arming, codes and troubles",
                             "what to do when something fails"]),
    "board administrator": (1, list(modules)),
}
for role, (n, mods) in people.items():
    h = sum(modules[m] for m in mods)
    print(f"{role:20s} {n} people, {len(mods)} modules, {h:.1f} h each")
sessions = sum(sum(modules[m] for m in mods) for _, mods in people.values())
print(f"trainer time if each role is trained together: {sessions:.1f} h")

concierge            4 people, 4 modules, 3.5 h each
property manager     2 people, 5 modules, 5.5 h each
board administrator  1 people, 8 modules, 9.0 h each
trainer time if each role is trained together: 18.0 h

Training each role together keeps the trainer's time down, but concierge staff work shifts, so Hollis schedules the concierge session twice. Each session uses the real system, with the trainees doing the tasks themselves on test cardholders and test alarms, not watching a demonstration. Each person signs the training record, and the record goes into the handover package.

Good training also covers the failures. What does the concierge see when a door goes offline, a camera stops recording or the alarm panel loses its communication path? Who do they call, and what do they tell residents? A short laminated sheet at the desk with those answers, and the service number, does more for the system's reliability than any feature.

Programming the intercom

The lobby intercom is programmed like a small access system of its own. Each resident unit gets a directory entry, usually showing a name the resident chooses or only the unit number, as the board's privacy policy decides, and a call destination, which at Juniper Point is the resident's phone through the intercom's app. The release action is mapped to the lobby door's relay or, better, to the access controller as a software command, so that every release is logged against the unit that granted it. The concierge station gets a call button and a release button for each entrance it covers, which is the assignment the witness test in the capstone catches. Delivery codes come from the management system with a time limit. As with every other device, the intercom's default administrator password is changed, its firmware updated and its directory export handed to the board, not kept by the installer.