SAT PREP

Jul 1, 2004 12:00 PM, By DON STURGIS

Most customers and system providers will agree that a Site Acceptance Test (SAT) must be performed for any physical security system. However, insufficient advance planning and test preparation can lead to disagreements about the extent and types of testing, incomplete testing, and dissatisfied customers.

This article will describe the Site Acceptance Test (also called the Field Acceptance Test) and provide detailed information about the first step of SAT tests: installation inspections. It will also address naming convention issues (for devices, zones and areas).

AD-HOC TESTING

Due to lack of detailed advance planning, Site Acceptance Tests are often improvised at the last minute. These ad-hoc test exercises are often designed to show specific features of the system, without wider consideration of customer needs. Ad-hoc testing can have the following negative results:

• incorrect or incomplete test setup, which requires “fiddling” with the system and creates suspicion in the customer;

• unnecessary problems that surprise the installer and lower customer confidence;

• testing performed from the installer's perspective rather than the customer's perspective;

• excessive questions from the customer (who was not adequately prepared to participate in the testing), which can lengthen the testing process and make it seem adversarial;

• disagreements over acceptability (i.e. what's critical, minor, cosmetic, etc.);

• customer accepting the system reluctantly because he suspects or did not completely understand the testing, sometimes feeling that it was a forced acceptance; and

• customer refusing acceptance unnecessarily.

Proper test setup, end-user participation and preparation prior to the SAT are critical to successful testing.

PURPOSE

Although the Site Acceptance Test contains some elements that are similar to the Factory Acceptance Test (see last month's article), the nature of the test is significantly different. Its purpose is to provide:

• proof of the completeness and accuracy of the system installation;

• proof of the correct operation of system functionality, as described in the system provider's documentation and in the customer's specifications (which should include security operations and response scenarios);

• verification of the completeness and accuracy of the system setup (cardholders, access privileges, camera setup, alarm names and descriptions, etc.); and

• demonstration of system functionality to the customer's personnel to the point that the customer is comfortable accepting responsibility for system operation.

The last point is extremely important. The customer has every right to be completely satisfied with the acceptance test and completely comfortable with the system provider. If the provider demonstrates high competence during acceptance testing, the customer is more willing to accept the system, even if all points of the test were not successfully executed.

There should be one Site Acceptance Test for each physical location — including each remote site, the host site and all workstation sites. For multiple-location testing at least a portion of the tests will be conducted with test personnel in two locations: the site system being accepted and the central monitoring facility.

The two key questions that the customer must have answered in order to accept the system are:

• Is the system installed correctly?
• Does the system operate correctly?

INSTALLATION INSPECTION AND SYSTEM DEMONSTRATION

For medium and large systems, the System Acceptance Test has two parts: Installation Inspection Tests and System Demonstration Tests. To answer the question “Is the system installed correctly?” requires inspections to show that specified devices are installed properly and in the correct locations (evidenced by the fact that they work correctly). These inspections should ensure adherence to specified end-user standards such as: conduit routing, cable routing, separation of power cables from signal cables and equipment placement. These inspections can be done by the customer's facilities engineering or equipment maintenance personnel.

The question “Does the system operate correctly?” is answered by demonstrations to show that devices are fully operational. Inspections and demonstration tests are performed using checklists. The checklists should be accompanied by a compliance matrix that cross-references each checklist item with the requirements to which it applies. The checklists are marked by the personnel performing the inspections and witnessing the demonstrations, which must include at least one person each from the customer's team and the system provider's team. Allowing system operators to participate in demonstration tests helps them become familiar with the various messages they will be viewing on a day-to-day basis.

SYSTEM PROVIDER-ORIENTED DOCUMENTATION

In preparing for site installation work, the system provider normally creates site layout drawings and riser diagrams. Point-by-point termination lists (specifying what wires get connected to what other wires or terminal block screws) are prepared; they are configured around the modularity of the hardware being installed. These will show the access control panels for a site and indicate the number of reader interface and input/output boards to be installed in each panel. Each of these points must be uniquely identified so that the installing technician knows where to connect the wires from each input/output device. The table below describes two panels located at a hypothetical Spruce Street Facility. The first panel contains two 2-reader interface boards, and one input/output board; the second panel contains one input/output board.

Augmenting this list is a book or set of detailed drawings that provide standard wiring connections for each type of input/output device being used in the system. One drawing would show what screw terminal on what terminal block is to receive each wire from a card reader. For instance, the two wires providing power to a reader may be connected to the reader interface board on terminal block 1 (TB1), terminal 1 and 2 (TB1-1 and TB1-2) for the first reader and to TB4-1 and TB4-2 for the second reader.

This kind of documentation is required for each remote site, and all sites containing the host computer and workstations. These documents should be revised by the system provider to reflect any wiring changes made to the system as a result of the SAT or any other testing.

END-USER-ORIENTED DOCUMENTATION

Although the documentation described above is important, it is not what the end-user needs to know or how the end-user should be preparing for the SAT. Instead, inspection and demonstration checklists should be developed to reflect ways the end-user will be using the system, and should be written in terms the end-user will understand. Here are some examples:

• create end-user checklists of all end-devices for each location containing equipment;

• make these checklists with end-user terminology, not installer's terminology;

• create end-user-defined names for each device location; and

• use names that are meaningful and still fit within the data field size and character limitations of the access control software.

To reiterate a point made earlier in this series: There can be only one basis for testing: the written information that the customer and the vendor provide to the project. With this in mind, before the SAT begins, there must exist one document for each site that lists every input device (i.e., reader, monitor or alarm point and camera) that is to be installed and every output device (i.e. gate, lights, motor or elevator) that is to be controlled by the system's output control devices (relays). There must be one entry in this document for each item shown on the site layout and riser diagrams that the system provider creates. The end-user must insist that these documents be in agreement.

Site: Spruce Street Facility

Panel	Panel IP Address	Board Address	Point Address	Board Type	Point Description	Location
A	9.10.11.100	1	1	Reader	Lobby Door	Front of building
“	“	1	2	Reader	Parking Lot Entrance Gate Pedestal	West Gate #1
“	“	2	1	Reader	Employee Entrance Door	West Door #1
“	“	2	2	Reader	Electrical Equipment Room	Electrical Equipment Room
“	“	3	1	I/O	Emergency Exit Door	Rear of Building
“	“	3	2	I/O	Motion Detector-West Side of Building	Center of West Hallway
B	9.10.11.101	1	1	I/O	Motion Detector-South Side of Building	Center of South Hallway
“	“	1	2	I/O	Motion Detector-East Side of Building	Center of East Hallway
“	“	1	3	I/O	Spare Input
“	“	1	4	I/O	Spare Input
“	“	1	5	I/O	Parking Lot Illuminator	West Side of Bldg at Camera
“	“	1	6	I/O	HVAC Emergency Shutoff	Electrical Equipment Room
“	“	1	7	Not Used
“	“	1	8	Not Used

The end-user should create his/her own separate checklist for each type of end-device in the security system (readers, input devices, output devices and cameras) and use these lists during the SAT. In the process of creating the checklists, the end-users get a basic understanding of the system. Savvy system providers will assist the customer in this task, or provide customer-oriented documentation which they carefully review with the customer. During the review, the system provider can determine the customer's level of understanding and can fill in any knowledge gaps as needed. Savvy customers will list this documentation and its review in their project requirements.

A single document form can work for both inspection and testing. One spreadsheet workbook should be created for each remote site, with a separate worksheet for each type of end-device. Each row of the worksheet should contain an end-device name. Each of the questions listed in the the sidebar below should be in individual columns. This creates a checkbox (cell) for each function to be tested for each device during the SAT.

DEVICE NAMES AND SECURITY MANAGEMENT

Deciding what to call each door, input/output point and camera is time-consuming and difficult. However, it is a task that must be performed by the end-user, and must be completed before the system can be set up for the Site Acceptance Test. (It's even better if it is done prior to the Factory Acceptance Test). It seems to be an issue about which most system providers do not give much help or direction to the customer.

Who decides on the naming scheme? It may have to be more than one person, particularly if the system encompasses several sites that are some distance apart. If the system operator is in a remote control center and will be contacting a local person to investigate the incident, what description will be most meaningful to the on-site investigator? The description should be in terms that the “locals” at the site use to identify a door or area. If more than one site is being monitored centrally, then the description should include the name of the site or an abbreviation for it.

Several things should be considered during the naming process. Is an input described as what is or what it detects? For example: “Motion Detector — South Side of Building” or “Intrusion on South Side of Building”? Is a camera named: “Camera Southeast Corner of Building” or is it better to name the area being viewed by the camera, such as: “Parking Lot”? Devices should be named in the way that is most useful to the system operators. Where and when will the names be displayed, and in what context? How will operators have to respond?

If there are a large number of devices or areas to be named, it is helpful to develop a naming scheme as a guideline. A practical way to develop a naming scheme is to select a small portion of the devices and areas to be named, and go through the exercise of naming them, keeping in mind the issues described here. Once one is happy with the results of the first set of names, how the names were developed can be documented and requirements can be established for addressing the rest of the names in a standard way.

Most access control software does not take the “user needs” versus “installer needs” fully into account in its database. Installers therefore often try to include the location of the system device in the system's name for the device. However, the system is going to be installed only once, but will be operated daily. It will only be serviced periodically. So it's most important that the names mean something to the daily operations personnel. Thus it is best to have the software contain the user's naming requirements, and keep separate written or electronic documentation containing the information the installers need.

SYSTEM-SPECIFIC CONSIDERATIONS

Before creating the name list, the vendor must provide documentation about how long each name or description data field can be. Each name field (reader name, input name, output name and camera name) in the computer software has a finite size. That is, each field can accommodate only “X” number of characters. More importantly, the name field may not accept some characters (# - _ and /). So the questions to ask are:

• what is the software field size (how many characters) for each of the devices?

• is this the only field used to uniquely identify this device? and

• what characters are acceptable to type in each field?

These may seem like simple requests but the answers may not be easily available. The system's User's Manual may not contain this information. It may be only available from the originator of the software. In the worst case, the system provider will have to examine the database to determine the size limits of each field. On one project, the author had to examine 150 pages of database file structures to obtain the field sizes for a particular system!

These issues are even more important when dealing with a multiple site system. The name field may be the only one used by the software to identify the location of a device, such as a reader. The name: “Lobby Door” is not sufficient. Is it the “Spruce Street Facility Lobby Door” or the “Elm Street Facility Lobby Door?” The name of the site must be part of each description.

Let's assume that the reader name field can accommodate 32 characters. “Spruce Street Facility Lobby Door” is 33 characters. If this description were used it would appear as “Spruce Street Facility Lobby Doo” — only the first 32 characters would be used. So consider shortening the facility name. In this example, Spruce would probably be sufficient. Moreover consider capitalizing the site names so that they are more obvious. So the two lobby doors could appear as “SPRUCE Lobby Door” and “ELM Lobby Door.”

Obviously, the more characters used for the site names, the fewer available for the point name. In come cases the site name may have to be a three- or four-letter mnemonic. This will work only if the mnemonics are meaningful to the system operators and local responders, and can be a training issue that is the responsibility of the customer.

FOR THE RECORD

ABOUT THE AUTHOR

Don Sturgis, CPP, is a senior security consultant for Ray Bernard Consulting Services (RBCS), a firm that provides high-security consulting services for public and private facilities. This article is excerpted material from the upcoming book The Handbook of Physical Security System Testing by Ray Bernard and Don Sturgis, scheduled for publication by Auerbach Publications in the spring of 2005. For more information about Don Sturgis and RBCS, go to www.go-rbcs.com or call 949-831-6788.

EQUIPMENT INSPECTION TEST QUESTIONS

End-users may not have a single source document (or worse — no documentation at all) that adequately describes each end-device. As a result, for example, when there is a problem with a camera, someone may have to climb a ladder to find out basic information about the camera before repairs can be made. The SAT preparations and the equipment inspection tests provide the opportunity to collect this information in one document or document set. Here are some questions to consider:

Inspection Questions for all Devices

• What is the make and model number of end-device?

• Is this the correct (specified) device for this location?

• Is the device installed correctly?

• Does the device have a tamper switch or other trouble indicator connected to the access control panel? If so, is each indicator listed on the end-user check list?

• Are there customer-oriented care and cleaning instructions for this device?

• Are these instructions appropriate for this type of installation?

Inspecting Questions for Cameras

(The inspection of cameras requires another set of questions)

• Is the camera black-and-white, color or color/black-and-white (day/night)?

• Is the camera fixed or pan/tilt/zoom (PTZ)?

• What is the lens type — manual focus/iris, manual focus/auto iris, variable focus/manual iris, variable focus/auto iris, motorized zoom/motorized iris or motorized zoom/auto iris?

• What type is the camera mount — wall-mount, ceiling, dome or pole?

• Is there an illuminator with this camera?

• If it's a digital camera, what is its IP address?

Inspecting Questions for Access Control Panels

It is important to document where each access control panel is located in the facility. Since there is little need to visit these panels during the day-to-day operations, there have been cases when an end-user has forgotten exactly where a panel was installed and had to go looking for it.

Most access control panels (cabinets) are equipped with trouble reporting indicators that should be checked during the Inspection Testing. Some common indicators are: tamper switch, loss of AC power, and low battery voltage.

The wiring inside the cabinets should be inspected. This inspection is not to see what each wire is connected to but to see:

• is the wiring neatly “dressed” and not draped over the printed circuit boards?

• can a circuit board be removed by unplugging the wiring termination blocks and disconnecting any mechanical mounting devices (screws or clips) without any interference from the wiring?

Some cabinets have a pocket or pouch attached to the inside of the door. Does the pocket contain:

• riser diagrams or other diagrams that show what specific end-devices are routed to this cabinet?

• “standard” wiring diagrams for each circuit board (module) in the cabinet?

COMING NEXT MONTH

System demonstration tests, test planning and preparation, test execution, documenting test results, and the roles of system providers, consultants and customers.

Want to use this article? Click here for options!
© 2012 Penton Media Inc.

This month in Access Control

• Targeting The Customer
• Electronic Pedigrees
• One Hero Among Many
• Who? What? When? Where? Why?
• More from September's issue