Understanding Functional Testing

Traditionally, functional testing is a process that occurs during the commissioning phase of a building new construction or retrofit.

When a building is commissioned, every piece of equipment must be inspected and functionality verified. Historically, this has been very arduous process where a commissioning agent goes to each piece of equipment and manually checks its operation. A report is then prepared, showing a checklist of issues found to the property owner. This is how that owner knows the work that they paid to have done was performed correctly.

In this age of digital command and control it is possible to automate this process and perform most functions remotely, and not just during the commissioning phase, but also at times afterwards to continue to validate operation. This is commonly referred to as Continuous Commissioning and where the KODE OS FTT (Functional Testing Tool) comes into play.

Functional Test Capability Requirements

Each device can have multiple components to test. The ability to perform continuous commissioning depends on a couple prerequisites:

• The device is templated correctly. All points required to test a particular component are available with the appropriate points writable.

• The program performing the test is able to write to points and receive feedback or detect that an action was taken during the test.

• Test results are stored in a database and easily accessible to the user.

• Tests can be automated and scheduled to run periodically.

Functional Testing @ KODE

KODE Labs maintains a library of Functional Tests that is designed for industry coverage of main component testing for common device types.  Currently, this library covers:

• Variable Air Volume (VAV) testing

• Heating Operation

• Damper Operation

• Parallel Fan Operation

• Fan Coil Unit (FCU) testing

• Heating Operation

• Cooling Operation

• Fan Operation

• Air Handling Unit (AHU) testing

• Heating Operation

• Cooling Operation

• Fan Operation (discharge, return, etc)

• Damper Operation (mixed, outside, etc)
  

• 
  

Some component testing is a prerequisite for others. For example, for an FCU, the fan must be operating in order to testing for Heating or Cooling operation. In these cases, the test is divided in sequences, each having its own passing criteria, scoring metric, and reporting.

Terms

• Workflow:  A testing sequence for a specific type of device that typically includes the following steps:

• Preconditions check:  Conditions that must be met in order to test desired component. An example of this would be making sure the parent AHU is running prior to testing one of its child VAVs.

• Setting up testing conditions: During this step, making sure that there aren’t any conditions that exist on the testing equipment that may interfere with test results.  For example, making sure that heating is in an “off” state prior to testing for heating operation where the first step is to put the heating operation in an “on” state.

• Performing the test(s): This is the meat-and-potatoes part of the workflow. In this part of the sequence, each test action is performed, each with its own validation criteria, reporting feedback, and scoring criteria (if more than one component is tested).

• Projects: This is the assignment of one or multiple devices to a workflow along with a time/date the test is to be performed.

• Test Result: This is the output of a job; each job will output one Test Result telling the user the steps that occurred while testing, the feedback received, and the success or failure of that test.

Test Results Landing Page

On this page, the default view is to see all of the test results from all jobs configured.

Page Structure

Navigate to the Test Results page by selecting the site of your choice and then choosing FTT from the main left sidebar. Click on the “View all” button at the top right corner of the page.

This page is divided into three main components.

• Filters: Click on ‘Filters’ button, to display the filter options at the top of the list.

• Search: Entering text into the search box will look for matches within the following fields:

• Building

• Device Name

• Device Type

• Area

• Workflow

• Test Results Table

• Sortable columns: Columns with up-and-down arrows next to the column name are sortable. The icon updates to indicate if the column is being sorted ascending or descending.

• Customizable column visibility & order: Clicking on the icon in the upper right of the table enables the user to hide and reorder columns.

• Pagination: At the bottom of the table, see information regarding the size of the table and page. Change the setting for “Lines per page” by clicking the blue number range, next to that text on the right.

• View the Test Result report: Click on a row to see the full details regarding that test.

Test Results Report

Test Information

Information associated with this test, including device, device location, initiating project or user, and workflow that directed the test.

• View Parameters: Click this button to view a table of parameters and values configured for this test.

Test Results

Comprehensive step-by-step reporting of testing sequence, success criteria, and feedback.

• Archive: Archive this test to remove it from downstream success calculations.

Quick Navigation

Quick navigation to other test results. The content of this list is determined by which KODE OS module you are viewing the report from. Click on a box to navigate to that report.

• If coming from the FTT Landing Page, it is the most recent test across the portfolio.

• If coming from Device Details, it is the past tests run on that device

• If coming from a Building page, it is a list of the most recent tests run on that building.

Device Test History

• Line chart representing testing score over time for this workflow and device.

• Breakdown of pass/fail for the sequences within the workflow as a bar chart to aid the user in identifying patterns in frequently missed sequences for a single device.