Inside the Dashboard: Charlie Cochrane’s Functional Testing Tool for Building Integrators

What does the Functional Testing Tool do?

For building integrators, functional testing becomes difficult at scale.

Testing one fan coil unit is manageable. Repeating the same test across hundreds of devices, documenting every step, identifying failures, and delivering a clear record to the client is where the process slows down.

Manual testing requires technicians to work through equipment individually. Results often end up spread across spreadsheets, reports, and disconnected project files. That makes it harder to maintain consistency, verify that every device was tested correctly, and isolate what caused a failed sequence.

The Functional Testing Tool (FTT) in KODE OS turns that work into a repeatable digital workflow.

Integrators can select a predefined test workflow, apply it across one or hundreds of devices, schedule when the tests should run, and control how many execute simultaneously. KODE OS then commands the equipment, verifies how it responds, scores the results, and records every step.

Instead of receiving only a pass-or-fail result, teams can see which part of the sequence failed, what the equipment was commanded to do, how the points responded, and what may have caused the issue.

The result is a structured functional-testing process that integrators can repeat across devices, floors, buildings, and portfolios.

How can I use it?

FTT takes integrators through the complete testing process, from selecting a workflow to diagnosing the results.

Here is how the workflow operates inside KODE OS:

Select a test workflow

Start by choosing a predefined workflow from the FTT library, such as an FCU heating or cooling test, VAV airflow test, or another equipment-specific sequence.

Each workflow includes the commands, parameters, conditions, and success criteria required to verify that the equipment is operating as expected.

Apply the workflow to the relevant devices

Search, filter, and select the equipment that needs to be tested.

The workflow can be applied to one device, a specific group, or hundreds of devices simultaneously instead of creating each test individually.

Control how the testing is scheduled

Run the project immediately or schedule it for a later date and time.

Devices can be grouped by floor, divided according to device count, or tested without grouping. Projects can also run on a recurring schedule, allowing teams to repeat testing weekly, seasonally, after system changes, or according to another commissioning requirement.

Limit simultaneous testing

Set the maximum number of tests that may run at the same time.

This gives teams control over how equipment is commanded and helps prevent too many devices from entering test conditions simultaneously.

Add project details and notifications

Give the project a name, description, and reason for testing. Users or entire roles can be notified so the right people know when testing begins and when results are available.

A related work order can also be connected to the project, keeping the testing activity tied to the wider commissioning or service workflow.

Review results and investigate failures

Once the tests are complete, use the FTT dashboard to see overall completion rates, failures, equipment scores, tested device types, test duration, and performance by area.

Open an individual result to review every sequence, command, response, timestamp, and pass-or-fail decision.

Create repeatable projects from predefined workflows

Functional testing should not depend on each technician rebuilding the process from scratch.

In the walkthrough, Charlie begins by selecting an FCU heating workflow from the FTT library. The workflow already contains the sequence required to test the unit, including its starting conditions, equipment commands, thresholds, and expected responses.

This gives integrators a consistent testing methodology.

Every device assigned to that workflow is evaluated against the same logic and success criteria. Results are therefore easier to compare across equipment, floors, and buildings.

It also reduces variation between technicians. The test does not change depending on who performs it or how they document the outcome.

Once a workflow has been established, it can be reused whenever the equipment needs to be validated again.

Apply testing across hundreds of devices

The real value of automated functional testing appears when the workflow moves beyond a single piece of equipment.

Inside the device-selection step, Charlie can choose individual FCUs or select the entire available group. In the example shown, the same workflow can be assigned across more than 700 devices without creating hundreds of separate test projects.

That changes the economics of commissioning.

Instead of spending additional manual effort for every device added to the scope, integrators can apply the same standardized process across the full equipment set.

Teams can use this capability to:

• Commission newly installed equipment.
• Validate devices before project turnover.
• Retest equipment after programming or control changes.
• Confirm that corrective work resolved the original issue.
• Run seasonal readiness checks before heating or cooling demand changes.
• Periodically verify performance after the initial commissioning period.

The test remains consistent regardless of how many devices are included.

Schedule testing around building operations

Functional testing frequently requires equipment to enter conditions that are different from normal operation. Running every test at once may be technically possible, but it is rarely operationally sensible.

FTT gives integrators control over how the project is distributed.

Selected devices can be grouped by floor or divided into smaller batches. Each group can then be assigned its own testing date and time. The number of simultaneous tests can also be limited.

For example, an integrator could test one floor each week, run tests outside occupied hours, or restrict execution to a small number of FCUs at a time.

Projects may run once or recur according to a defined schedule. This makes FTT useful beyond initial commissioning. The same test can continue validating performance during seasonal transitions, warranty periods, and ongoing service agreements.

Functional testing becomes an ongoing operational process rather than a one-time project deliverable.

See building-wide results in one dashboard

After the tests run, the FTT dashboard provides a centralized view of performance.

Integrators can review:

• The number of tests executed.
• The number and types of devices tested.
• Average test duration.
• Completed and failed workflows.
• Average scores by area.
• Overall test status.
• Performance trends over time.

This makes it possible to move from individual device results to a broader view of system performance.

A project manager can quickly determine how much of the test scope has been completed. A commissioning engineer can identify areas with lower scores. A service team can focus on the devices that failed instead of reviewing every successful test individually.

The dashboard also creates a clearer record for client communication. Rather than compiling results manually, teams have a consistent view of what was tested, when it ran, and how the equipment performed.

Investigate the exact sequence that failed

A failed test is only useful when the team can understand why it failed.

Inside each result, FTT shows the complete test sequence as a chronological record. Every initialization step, command, condition, equipment response, and decision is documented with its timestamp.

The walkthrough shows an FCU heating test that failed during the Stop Heating sequence.

The system commanded the hot-water valve to close, but the discharge-air temperature did not fall below the specified threshold within the allotted time. A later Start Heating sequence passed, confirming that the unit could produce heat even though it did not stop heating as expected.

That distinction matters.

A simple failed status would tell the integrator that something went wrong. The sequence-level result shows exactly where the expected operation broke down.

Teams can also review score history and passed-versus-failed sequences, making it easier to determine whether the failure is isolated, recurring, or connected to a particular part of the workflow.

Use AI to accelerate root-cause analysis

Each test result also includes AI-generated diagnostic guidance.

KODE OS reviews the failed sequence and presents:

• A summary of the problem.
• Potential root causes.
• Confidence levels for each possible cause.
• Recommended next steps for investigation.

For the failed FCU heating test shown in the video, the AI analysis identifies several possibilities. These include a hot-water valve that may not be closing correctly, an issue with the heating setpoint or control logic, and inaccurate discharge-air-temperature readings.

It then recommends specific checks, such as inspecting the valve, comparing the commanded position with its actual response, reviewing the control sequence, and validating the temperature sensor.

The AI does not replace the integrator’s technical judgment. It gives the team a more focused starting point.

Less experienced technicians receive a structured troubleshooting path. Experienced engineers gain a fast second opinion and can move directly to the most likely causes instead of reconstructing the entire event from raw point data.

Why this matters

Traditional functional testing becomes harder to manage as the number of devices, systems, and buildings increases.

More equipment usually means more manual execution, more documentation, more spreadsheets, and more opportunities for inconsistent results.

FTT changes that relationship.

One structured workflow can be applied repeatedly across hundreds of devices while maintaining the same test logic, thresholds, scoring, and reporting process.

For building integrators, that means:

• Less repetitive manual testing.
• Consistent validation across every device.
• Clearer documentation for project handover.
• Faster identification of failed sequences.
• More focused troubleshooting.
• Repeatable testing after changes or repairs.
• A testing process that can scale from one building to an entire portfolio.

Instead of proving that equipment worked only at one moment during commissioning, integrators can create an ongoing record of how it performs over time.

See it in action

From selecting a predefined workflow to scheduling hundreds of device tests and diagnosing individual failures, FTT brings the complete functional-testing process into KODE OS.

In this edition of Inside the Dashboard, Charlie Cochrane walks through how building integrators create testing projects, control when and how tests run, review performance at scale, and use AI-generated guidance to investigate failed sequences.

To explore how the Functional Testing Tool can support commissioning and equipment validation across your projects, connect with us on LinkedIn or book a demo with our team.