Estimated reading time: 10 minutes
Functional Descriptions for Building Management Systems
Preserving Engineering Knowledge Beyond Practical Completion
A Building Management System (BMS) is only as good as the engineering decisions behind it.
Controllers can be replaced. Networks can be upgraded. Graphics can be redesigned and software rewritten. Yet the single most valuable asset in any Building Management System is often overlooked—the Functional Description.
A Functional Description records how a building is intended to operate. It captures the engineering intent behind the control strategies, allowing owners, consultants, contractors and future facility managers to understand not only what the system does, but why it does it.
Unfortunately, many commercial buildings either have no Functional Description, have one that was never completed, or possess a document that no longer reflects the building as it actually operates. The result is uncertainty, unnecessary costs, inefficient operation and an increasing dependence on the contractor who originally programmed the system.
At WR8Tech, we believe a Functional Description should be regarded as a living engineering document. It should evolve as the building evolves, preserving valuable operational knowledge throughout the life of the asset.
What Is a Functional Description?
A Functional Description is a written engineering document that explains how a Building Management System is intended to control the building.
It is not the software itself.
It is not the controller program.
It is not a wiring diagram.
Instead, it describes the operational philosophy of the building in plain engineering language before a single line of software is written. Think of it as the blueprint for the control strategy.
If a programmer can understand exactly how the building should behave by reading the Functional Description, then the document has achieved its purpose.E
More Than a Programming Guide
Many people mistakenly believe a Functional Description exists only for the BMS programmer. In reality, it serves a much broader purpose. A well-written Functional Description becomes the common engineering reference used by:
- Building owners
- Property managers
- Facility managers
- Mechanical engineers
- Electrical engineers
- Commissioning engineers
- Mechanical contractors
- Controls contractors
- Independent consultants
- Future maintenance providers
Years after practical completion, it often becomes the only reliable explanation of why the building operates the way it does.
The Three Versions of Every Building
One lesson repeated across countless existing buildings is that there are rarely just one version of the building.
Instead, there are usually three.
01
The Building That Was Designed
This is the engineer’s original intent.
It exists within specifications, design drawings and Functional Descriptions.
02
The Building That Was Commissioned
During commissioning, practical adjustments are made.
Schedules change. Setpoints are refined. Equipment sequencing is optimised. Minor operational improvements are introduced. Variations implemented. The commissioned building is often different from the original design.
03
The Building That Exists Today
Years later the building has evolved again. Tenants have changed. Plant has been replaced. Energy-saving measures have been introduced. Temporary overrides have become permanent. Fire interfaces have been modified. Software has been edited by multiple contractors. Minor and major Projects have been completed. Tenants have come and gone. Technology has changed. Compliance Requirements have changed
Very little of this would have been formally documented.
Without an updated Functional Description, these three versions slowly drift further apart until nobody can confidently explain how the building is actually intended to operate.
Why Every Commercial Building Needs One
A Functional Description reduces uncertainty.
It creates consistency between contractors.
It supports accurate commissioning.
It simplifies troubleshooting.
It protects engineering knowledge during staff changes.
Most importantly, it protects the building owner.
Rather than relying upon the memory of one programmer or one service contractor, the operational philosophy belongs to the building itself.
What Should a Functional Description Include?
While every building is different, a comprehensive Functional Description should generally include:
System Overview
- Building description
- Systems served
- Design objectives
- Operational philosophy
Plant Operation
Detailed sequences for:
- Air handling units
- Chilled water systems
- Heating hot water systems
- Condenser water systems
- Cooling towers
- Boilers
- Variable refrigerant systems
- Car park ventilation
- Smoke management systems
Control Sequences
Clear explanations of:
- Start-up
- Normal operation
- Shutdown
- Occupied mode
- Unoccupied mode
- After-hours operation
- Night purge
- Economy cycle
- Demand limiting
- Load shedding
- Seasonal operation
Inputs
Every sensor, switch and measured value that influences operation.
Outputs
Every fan, pump, valve, damper, relay and Variable Speed Drive controlled by the BMS.
Alarm Philosophy
- When alarms occur.
- Who receives them.
- How they reset.
What constitutes a critical alarm versus an advisory notification.
Interfaces
- Fire systems.
- Energy meters.
- Lighting.
- Lift systems.
- Medical systems.
- Access control.
- Solar systems.
- Embedded energy networks.
- Anything that exchanges information with the BMS.
Setpoints
- Normal operating values.
- Allowable adjustment ranges.
- Engineering units.
- Control tolerances.
Trend Logs
- Points to be logged.
- Sampling intervals.
- Retention periods.
- Purpose of the data.
Reporting
- Energy reports.
- Runtime reports.
- Fault reporting.
- Performance reporting.
What Doesn’t Belong?
One of the most common misunderstandings is trying to include every technical detail within the Functional Description. That is not its purpose. Items such as:
- Controller source code
- Network addresses
- BACnet device IDs
- IP addresses
- Passwords
- Panel layouts
- Cable schedules
- Manufacturer-specific programming
should be maintained within their own engineering documentation.
A Functional Description should remain largely vendor independent. Its purpose is to describe how the building should operate, not how one manufacturer’s software achieves it.
The Biggest Mistake We See
Many Functional Descriptions contain statements such as:
“The BMS shall control the Air Handling Unit.”
Unfortunately, that sentence tells nobody anything useful. A proper Functional Description should answer questions such as:
- When should it start?
- Why should it stop?
- What conditions enable operation?
- What happens during a fire alarm?
- How are faults handled?
- What occurs if a sensor fails?
- What happens after a power failure?
Good engineering documentation explains the decision-making process behind the control strategy, not simply the existence of one.
Protecting the Building Owner
One of the greatest benefits of a Functional Description is that it protects the owner’s investment.
Without proper documentation:
- Future contractors must make assumptions.
- Programming changes become higher risk.
- Commissioning becomes more difficult.
- Troubleshooting takes longer.
- Quotations become harder to compare.
- Operational knowledge slowly disappears.
The building becomes increasingly dependent upon whichever contractor happens to understand its history.
That dependency carries both financial and operational risk.
Reducing Vendor Lock-In
This is not about criticising any particular BMS manufacturer or contractor.
Most contractors work professionally and deliver excellent outcomes.
However, where documentation is incomplete or never updated, a practical problem can emerge.
The service contractor may become the only organisation that truly understands how the building operates.
Changing contractors then becomes expensive—not because the hardware cannot be maintained, but because years of operational knowledge exist only in one organisation.
A comprehensive Functional Description helps ensure that knowledge remains with the building owner.
A Living Engineering Document
Buildings are not static. Over twenty or thirty years they continually evolve.
Mechanical equipment is replaced.
Energy strategies are refined.
Tenants change.
Operating hours change.
Control philosophies improve.
Refurbishments occur.
Each significant change should be reflected within the Functional Description. It should never be regarded as a document that is completed at Practical Completion and then forgotten.
Instead, it should become part of the permanent engineering record of the building.
The Cost of Not Updating It
Across existing commercial buildings, we regularly encounter situations where:
A Variable Speed Drive has been replaced without updating the control strategy.
Outside air control has been disabled during a temporary issue and never restored.
Temperature sensors have been relocated without documentation.
Fire interfaces have been modified during refurbishments.
Control loops have been bypassed.
Schedules no longer reflect occupancy.
None of these changes are necessarily difficult to resolve. The difficult part is discovering that they ever happened. That investigation consumes time, increases costs and often delays improvements that could have been avoided with accurate documentation.
Engineering Knowledge Is an Asset
Buildings are long-term assets.
Engineering knowledge should be treated the same way.
A Functional Description is far more than a project deliverable.
It records why the building behaves as it does.
It supports future commissioning.
It enables better maintenance.
It assists future upgrades.
It protects operational continuity.
Most importantly, it ensures that valuable engineering knowledge is not lost each time a contractor changes, a refurbishment occurs or experienced personnel retire.
Conclusion
Software will change. Hardware will eventually be replaced. Networks will continue to evolve.The engineering principles behind a well-performing building, however, should endure for decades.
A carefully prepared and regularly maintained Functional Description preserves those principles. It provides owners, facility managers and future engineers with confidence that the building’s operational intent has not been lost over time.
At WR8Tech, we believe documentation should do more than satisfy a project requirement. It should preserve engineering knowledge, reduce lifecycle risk and protect the long-term performance of the building.
Because once the knowledge of why a building operates the way it does is lost, recovering it can take years—and sometimes it is never fully recovered.
