1. OVERVIEW
Testing ensures that systems and assemblies meet the performance criteria for which they were designed.
Observation focuses mostly on the visual inspection of whether a particular system or assembly is installed as specified, whether the correct components were selected, installed without damage, and whether the installation meets the criteria set forth in the OPR in terms of maintainability, access, and the like.
A test is substantially different from an observation in that the performance of the system or assembly is examined rather than its physical presence.
Testing for performance frequently means altering the operation of the system or assembly to evaluate responses against expectations. To clarify the different types of testing that can be employed, the following definitions may be used:
Performance Test (PT or FPT): Performance Testing is the process of verifying that a material, product, assembly, or system meets defined performance criteria. The methods and conditions under which performance is verified are described in one or more test protocols.
Performance Test Protocol: A Performance Test Protocol is a written collection of tests that, when executed in the test process, allow verification of the performance of a system or assembly.
Performance Test - Active Test: Execution of an active test forces the system or assembly from one operating state to another through operator interaction. The test description includes the definition of a starting state and an expected response state. The test description also includes the operator interaction required to force the system into the expected state and the type of monitoring and data recording required.
Performance Test - Passive Test: Execution of a passive test records the starting state or if necessary, places the system or assembly into a pre-defined starting state and monitors the occurrence of response states over a passage of time without operator interaction. The test description includes the record of a starting state, expected response states, and describes the amount of time required to elapse before test completion, as well as the type of monitoring and data recording required. During execution of the test, the actual response states are recorded.
2. PERFORMANCE
These definitions shown above apply to all types of systems and assemblies and are not tied to any particular discipline in the construction process. Performance as a generic term can be
54 of 76
identified to include all physical (and physically measurable) performance parameters such as leak tightness, electrical efficiency, solar absorption efficiency, vibration isolation, and the like.
Note that color, weight, or size are not performance parameters. They are physical properties of the system and assembly, and as such, are not performance tested. These properties will affect the performance.
For example, the color of a solar collector will influence its conversion efficiency, but the resulting efficiency is the performance parameter that is tested, not the color.
Next to these measurable parameters, there are also logical or operational parameters that can be tested.
Example: the correct reaction of a security system that responds to an access key card being swiped at a door is a logical performance test – the performance being tested is the control system response rather than the physical operation of the door lock itself.
3. LEVELS OF COMPLEXITY
To test systems and assemblies in a systematic manner, it is important to initiate testing at a low level of system or assembly complexity, and work up to the highest level. This concept is difficult to define exactly since the definition and meaning of terms such as component, system, and assembly changes depending on the viewpoint of the observer:
As an example, the security system test described above could proceed in several steps: the lowest level of complexity tests whether a door lock mechanism operates when power is applied and correctly manages to lock/unlock the door as desired. A follow-up step might be a test that examines the interaction of one door/card reader combination and verifies whether the door lock is triggered by the introduction of the card. A higher level test still would be the verification of multiple access cards with different access rights linked to schedules (card A is allowed entry 24/7, card B is only allowed access from 8AM to 5PM).
For every system or assembly, testing can thus be conducted by defining what levels of complexity are to be addressed, what actions are taken to challenge a system, and what responses are expected. The definition of levels of complexity and levels of systems depends largely on the expertise of the author of test protocols and the wishes of the Owner as expressed in the OPR.
As an example of system definitions, a test protocol could be based on using a chiller as a component in a chiller plant. The system in this case is the plant, components are chillers and pumps. Low level tests would examine whether the chiller operates when commanded to do so;
higher level tests would examine whether multiple chillers stage correctly in response to load.
However, if additional attention to detail was desired, each chiller itself could also be defined as a system consisting of multiple compressors, variable speed drives and on-board controls with potentially far more complexity than a chiller plant consisting of 2 chillers and 2 pumps. The response of the chiller system to sudden load changes without freezing could thus be tested, or the ability to maintain a steady chilled water temperature within tight tolerances, or the ability to restart quickly after a power outage.
The reverse could also be true – in a case where multiple, existing chiller plants are interlocked as part of a new project to provide additional redundancy, neither the testing of an individual chiller nor even the testing of each chiller plant may be required; instead, the interaction of the
55 of 76
various available chiller plants on campus and their ability to correctly respond to failures of one plant by increasing the capacity of another plant may be appropriate.
Thus, the number of levels of complexity and the number of levels of systems versus components or sub-systems is entirely project dependent. The clarification of testing levels should be provided by the author of the tests, and the Owner should make a decision concerning the level to which such possible testing should be conducted.
Typically, a fairly high level of expertise is required to understand not just the available test methods and cost, but also to make an appropriate selection of which type of test will best verify whether the actual owner’s needs will be met: The mental step of translating the Owner’s wishes (as expressed through the OPR) into performance criteria that can be tested and verifying that test protocols encompass all of those performance criteria is not trivial. Care should be taken to ensure that those accepting test protocols before their execution, such as the Owner, are assisted by technical personnel able to provide background information and plain-text explanations of what tests are required, why they are required, what costs associated with different levels of testing make sense, and what risks are associated with testing.
As a final example linked to the previous chiller plant, an owner may not require a high degree of business continuity because they do not have a critical facility such as a data center. In this case, creating test protocols that examine the chiller’s ability to restart quickly is entirely possible, but it adds little value. Conversely, failing to include a test protocol for quick restart in a data center project may fall short of meeting the Owner’s needs – thus, all tests could be written and perfectly executed while still failing to meet the desired level of performance.
Despite the difficulty in describing the boundaries of systems and assemblies exactly, a general description of the execution of tests in order of complexity is as follows: tests should be conducted in order of complexity, starting with the simplest systems or assemblies. Tests of simpler systems and assemblies should be passed successfully before tests of more complex systems and assemblies are undertaken. In general, the level of complexity is proportional to the number of components and physical or logical interactions between components. For purposes of Cx, only those physical or logical interactions which are captured in test protocols determine the relative complexity of the system or assembly; in other words, complicated “black box” systems or assemblies are relatively simple from the point of view of the Cx agent, even though they may be complex from the manufacturer’s or contractor’s point of view. The definition of what physical or logical interactions are captured in test protocols is the responsibility of the Owner, with substantial support from the CxA and related technical experts on the Cx Team.
4. ACTIVE vs. PASSIVE TESTING
Most of the examples given above relate to active testing. This involves purposefully changing the operating state of an assembly or system to evoke a response and comparing the response to the expectation shown in the test protocol. Usually, this is done by physically being present at the system or assembly and observing the responses as they occur.
Active test example: all openings (doors, windows) in a building are closed, and the building is pressurized with a blower assembly. The air passing through the blower/fan is measured, and the result is converted in to an envelope leak rate for the building.
Active test example: a person enters a room, and the lights turn on in response to the occupancy sensor. The person leaves the room and lights turn off again after the timer has elapsed.
56 of 76
It is possible to capture a large degree of functionality in this manner, but typically not possible to verify all the performance that was desired in the OPR. To augment these tests, which rely on intentional interaction with systems and assemblies in the field, a second type of test is required.
This type of test is a passive test, in which the performance of systems and assemblies is evaluated WITHOUT intentional interaction by test personnel. In many cases, this type of testing involves more long-term results which are not practically obtainable in the field.
Passive test example: the actual efficiency of solar panels on a daily cycle is tested for comparison against manufacturer data and expectations upon which the design is based.
Irradiation meters record the solar intensity over a period of several weeks, and the power output of the panels is measured using a power meter with the ability to communicate with the building management system or with its own data logging capabilities. Several weeks of data are examined, and the panel performance is evaluated for sunny and cloudy conditions.
Passive test example: the scheduling system in a building is examined after turn-over to the customer. Using data loggers or the building control system, the status of selected lighting, security, mechanical, and electrical systems is recorded to determine whether systems shut off as desired when schedules command and whether the use of local overrides and adjustments by tenants causes unintended interactions that result in systems remaining in operation. Several weeks of operation, including changes between weekdays and weekends, can be examined to verify overall performance.
As the examples above illustrate, the methods employed in executing an active and a passive test are substantially different, and they require different tools. The types of performance that can be measured with active and passive tests may overlap but are often complementary. Both types of tests are usually required to comprehensively address the ability of systems and assemblies to meet owner’s requirements.
Construction Observation and Testing Checklists and Report
OVERVIEW
Construction Checklists consist of two general types:
Component/Equipment Based: these Construction Checklists are utilized for components and pieces of equipment that are delivered, installed, and started up during construction. There is an individual checklist for each individual component or piece of equipment.
System/Assembly Based: these Construction Checklists are utilized for systems and assemblies where separate checklists cannot be applied to sub-components of the system or assembly. There is a single checklist for the entire system, often assembled around the sequence of operation.
For each Test Procedure, Test Data Records shall be developed. Test Data Records capture test data, observations, and measurements. Data may be recorded on photographs, forms, or other means appropriate for the application. The following information shall be recorded:
1. Test number.
2. Date and time of the test.
3. Indication of whether the record is for a first test or retest following correction of a problem or issue.
57 of 76
4. Identification of the system, equipment, or assembly under test. List the location and the construction document designation.
5. Conditions under which the test was conducted.
6. Expected performance of the systems and assemblies at each step of the test.
7. Observed performance of the system, equipment, or assembly at each step of the test.
8. Issue number, if any, generated as a result of the test.
9. Dated signatures of the person performing the test and of the witness, if applicable.