GSA Smart Buildings Implementation Guide_v12.pdf

GSA Public Building Service Facilities Management & Services Program

GSA Smart Building Implementation Guide Version Control

Revision Date Description

1.2.0 5/14/18 Corrections and update to Point Naming Standard

1.0.0 6/10/15 GSA Smart Building Implementation Guide

Table of Contents 1 Introduction

1.1 Audience and Use

2 Smart Building Attributes

2.1 Open/ Converged/ Normalized – All Systems

2.2 Master System Integrator

2.2.1 Unified User Interface

2.2.2 Integrated Sequence of Operations

2.3 Building Automation Systems

2.3.1 BAS Controllers

2.3.2 BAS Software

2.3.3 BAS Communication Protocols

2.3.4 Point Naming

2.3.5 Minimum Point Lists

2.4 Digital Lighting Control

2.4.1 Shade Control

2.5 Metering and Sub-Metering

2.5.1 Utility Metering

2.5.2 Sub-metering

2.5.3 Automated Demand Response

2.6 Digital Signage

2.7 Hoteling

2.8 Occupancy Counting

2.9 Native Power

3 Other Smart Building Project Considerations

3.1 System Design

3.2 Commissioning

3.3 Training

3.4 System Maintenance

1 Introduction

The GSA Smart Buildings Implementation Guide is intended to assist GSA project managers, tenant agencies, architectural and engineering firms and general contractors on all GSA funded new construction or R&A projects to understand and implement the attributes of “smart buildings”.

This guide should be used in conjunction with the GSA Smart Building Program Guide, the PBS P100 Facilities Standards for Public Building Services and The GSA Building Commissioning Guide, to ensure all GSA properties meet the agencies expected performance and building system configuration.

1.1 Audience and Use

As part of any project Prospectus period, the GSA Smart Buildings Program Guide should be used to determine which, if any, smart building systems will be implemented in the project. These decisions are based on budget, goals and limitations that are unique to each project. From this prospectus, a list of building systems and features should be determined. The GSA Smart Buildings Implementation Guide is designed to expand on that set of building systems and features and to help provide conceptual guidance language for implementing each of those systems. The Implementation guide should be used by GSA project managers, architectural and engineering firms, general contractors and anyone else writing specifications for a GSA projects that have smart building implementations.

The Implementation Guide is broken into sections that focus of specific building systems and features of the systems. Every section has an introduction to the building system followed by “Requirements”, “Recommendations” and “Considerations” for each system. The requirements are the minimum system configuration and features that should be applied to every system, should it be included in the project. Recommendations are the features and configurations that are not necessary for a successful smart building system but can add value, increase efficiencies or somehow otherwise improve the system. Considerations are additional features, system interactions or design aspects that should be considered when implementing the system.

2 Smart Building Attributes

2.1 Open/ Converged/ Normalized – All Systems

As defined in The GSA Smart Buildings Program Guide, all building systems must meet the Smart Buildings Pillars’ requirements of Open, Converged and Normalized.

O/C/N Requirements:

• All building systems shall utilize open protocols where available.

• All building systems shall reside on a converged network infrastructure*, coordinated and managed by GSA IT Services as defined in the Building Technology Technical Reference Guide.

• To facilitate normalized data, all building systems shall use GSA point naming standards or coordinate naming conventions with the GSA project manager if existing standard cannot be used.

* Systems that require specific network configurations for code, security or life-safety concerns are excluded from this converged network

2.2 Master System Integrator

Several aspects of Smart Buildings can be effectively realized by strategically executing with an MSI leading the integration side of the project. Individual building systems were historically installed by the local vendors and operated as stand-alone systems. Open, converged and normalized buildings now allow these systems to communicate with one another and to control the building as a single intelligent entity. Introducing an MSI allows a single contractor to take responsibility for integrating these individual systems and ensuring that the building is controlled holistically. MSIs also open the door for more potential smart buildings aspects like unified user interfaces or integrated sequences of operations.

The role of the MSI varies greatly by the technical capability of the MSI and the goals and requirements of the project. At a minimum, the MSI’s role is to coordinate the network convergence and ensure the individual systems are connected and coordinated properly. In more complex projects, the MSI may take on the role of system integrator to engineer integrated sequences of operations and user interfaces. It is important to define these expectations when introducing the MSI role.

Requirements:

• MSI shall be responsible for managing converged network design and coordinating with GSA IT Building and Energy project managers.

• MSI shall be responsible for ensuring communication between disparate systems.

• MSI shall support commissioning agents and act as the “smart buildings commissioning agent”, ensuring system integration and open protocol usage.

• MSI shall implement integrated sequence of operations (when applicable).

• MSI shall be responsible for Unified User Interface (when applicable).

Recommendations:

• MSI should be responsible for coordination of sub-system installing contractors, including system commissioning and network integration.

• MSI should enforce point naming standard and labeling consistency across sub-systems.

• Sub-system sequence of operations should be coordinated with the MSI to ensure the holistic operation of the building is considered.

Considerations:

• The role of the MSI depends on cooperation from sub-system installing contractors.

Contracting the MSI as an “on-par” contractor with the electrical or mechanical contractor, or consider adding language to sub-contractors’ requirements to ensure this cooperation.

2.2.1 Unified User Interface

A UUI is a singular graphical user interface that can be used to monitor and control various building systems. When implementing a UUI it is important to ensure that the interface include graphics for monitoring and controlling the systems for daily operations and maintenance. This user interface should be the centralized tool for O&M contractors and building managers to operate a building.

UUI’s should be considered when multiple systems will be maintained by one contractor. In addition to reducing the learning curve for operations on multiple systems and offering a central location for building control, unified user interfaces offer an opportunity to reduce the cost of the development of graphics on each individual system interface. When implementing a UUI it is important to limit graphics requirements from the scope of any other system. A UUI is often implemented by a master system integrator and should be considered if an MSI is appropriate for the project Requirements:

• UUI shall include access control levels to allow for viewing, controlling, and administration.

• When implementing a UUI, sub-system installers shall not develop individual graphics for sub-system console control.

• UUI shall provide methods for controlling, reporting and overriding sub-systems.

• UUI shall require unique usernames and passwords for every user. Generic usernames

(i.e. “admin” or “engineer”) are not permitted.

• UUI shall allow for system audit, allowing for system logging of user access and control.

This log shall show history of users entering and leaving system as well as any point status changes made by user. Log shall include username and timestamp of each action.

• UUI should be “point and click” navigation allowing for intuitive navigation and control.

• UUI should include help screens that help users to navigate systems and control sub-systems.

Considerations:

• Typically, a UUI will not completely replace configuration software or engineering tools.

This software will likely be needed for system programming and hardware maintenance.

The intent of the UUI is to provide a tool for much of the “day to day” building control.

2.2.2 Integrated Sequence of Operations

Successful designs hinge on the smooth, integrated interaction between the systems installed in a building and the functions they are to perform. Integrated Sequence of Operations (ISOO) allow for more unified controls strategies and can not only save energy but improve the tenant experience. By allowing building systems to act in unison and react to changing conditions identified by each system, a smarter, more efficient solution can be realized. Integrated sequences should be considered in all designs and their successful implementation may benefit from an MSI to ensure proper coordination between multiple systems.

Requirements:

• Integrated sequences of operation shall be verified as part of the commissioning process.

• ISOOs must be programmed and tested to verify that a loss of communication between systems does not cause unexpected results from either system.

• When utilizing ISOOs, systems shall be configured to run in a default mode in cases of communication loss

Recommendations:

• ISOOs should be programmed by the Master System Integrator with the input of the system owner, tenant and building system installers.

• ISOOs should be designed in a manner that allows them to be easily manipulated by the system owner, allowing for “stand alone” or “integrated” operating modes.

• ISOOs should include occupancy based sequences, emergency scenario sequences, and other sequences developed by system owners.

Considerations:

• ISOOs are a chance to integrate multiple systems and allow the building systems to act as a complete, single system. Some of these new sequences will change the way tenants and building operators interact with the building. Careful documentation and education needs to be included in system turnover. System operators need to understand that the triggers for actions in one system may come from another and need to understand how to disconnect the systems to test and verify modifications or repairs.

2.3 Building Automation Systems

Building Automation Systems (BAS) are often thought of as the central system for smart buildings.

These systems are designed to control the Heating, Ventilation and Air Conditioning (HVAC) equipment from the chiller plant to the thermostat on the wall. HVAC is a major energy consumer in most commercial facilities and therefore offers a big opportunity for energy savings.

2.3.1 BAS Controllers

Building Automation systems generally rely on network controllers that communicate to a server and control edge devices. These controllers are general to the system engines, making much of the control decisions.

Requirements:

• Building automation systems shall be 100% direct digital control (DDC) systems, utilizing a server, controller, edge device hierarchy.

• BAS Controllers shall be programmed to maintain schedules, set point and normal operation control in cases of network connection loss. Network connection loss scenarios shall be tested and verified as part of the commissioning process for any BAS.

Recommendations:

• BAS controllers should be capable of storing data and uploading data in case the server connection is lost.

• BAS controllers should host graphics or terminal interfaces to allow for direct connection and control from a workstation for emergency control. This could be accomplished over IP, serial or USB connections.

• BAS controllers should be capable of network-wide management for patching and updating. This capability gives the system owners and vendors an easy method for remediating any security vulnerabilities discovered without requiring physical presence at every controller.

• BAS Controllers should have embedded tools or means to direct connect that allow for troubleshooting or programming in cases of communication loss. Means to “direct connect” to building system controls could include IP, Serial cable or USB connectivity options.

Considerations:

• As technology has advanced, more and more of the computing and logic of the building system has moved from the server to the controller. These controllers have less reliance on network connectivity for executing the control sequences, and utilize the server as a historian and management connection. This system configuration should be considered for new building automation system installations.

2.3.2 BAS Software

Buildings systems traditionally rely on network management software, application configuration software, system monitoring software and other system software tools for operating and maintaining a building system.

Requirements:

• BAS software must be installed in the GSA environment, including server software, client software and any additional tools needed for management and control of the system. This includes system update tools, network management tools and any software that is used to make changes to the controllers.

• BAS software shall be compatible with the most current version of required standard software and all OS and database software updates (i.e. Microsoft Server, Linux, SQL, etc.)

• BAS software must be capable of trending and exporting data.

• BAS software shall have multiple user level controls, including administrator, programmer and users. These user levels shall be capable of an audit to determine operator’s use.

• BAS software credentials shall be unique for every user.

• BAS software shall be installed with a minimum number of licenses needed for system use. In cases of virtual environment installation, the number of licenses required should consider the cases that client use could come from an off-site user.

• BAS client software shall have point and click graphics, configured for system operators, unless a Unified User Interface is included in the project scope.

• BAS software licenses shall be software licenses and not rely on a physical license key or dongle.

• BAS must be licensed to GSA. End user license agreements (EULA) must be approved by GSA IT prior to installation onto GSA equipment.

• BAS software should be capable of residing on a virtual server and on a separate VLAN from the devices. This software includes the server, client, and management tools.

• BAS client software should be a thin-client, allowing for an unlimited number of users to access graphics and system management tools via a web browser on a connected network.

• BAS software should support open protocols, open support structure and open integration for third party software.

Considerations:

• When configuring BAS software for the GSA, the virtual environment of the BSN should be understood and the system should be configured to best meet the requirements and challenges the BSN produces. This includes the desire of the GSA to build a single server to run all applications needed for building control including server and client software.

2.3.3 BAS Communication Protocols

Requirements:

• BAS Systems shall utilize BACnet or LonMark communication protocols:

o Because Layer 2 network traffic cannot be effectively managed currently on the

GSA network between subnets, BACnet/Ethernet is expressly prohibited from being implemented on the GSA WAN. BACnet/Ethernet can be used at a given field site, provided all devices are on the same subnet.

o All device instance numbers associated with a BACnet network must be unique.

This can be challenging on the GSA network because a vendor installing a BACnet system is likely not aware of the device instances of other BACnet systems that have devices, which may be discoverable over the GSA WAN.

To prevent BACnet collisions, systems with BACnet devices communicating on the network must comply with the GSA’s UDP port range requirements. 24 unique UDP ports have been assigned to each region. Vendors must coordinate with the region on any additional details regarding UDP port designations within these ranges as their individual management requirements may differ (building based, vendor based, etc.).

• Multicasting is not allowed on the GSA WAN, and should not be applied when configuring a BACnet system on the GSA network.

2.3.4 Point Naming

GSA has created a point naming convention for standardization of point naming for all new construction, ESPC and R&A projects. The intent of this standard is to establish and require a consistent means of naming building automation points across the GSA portfolio. The term ‘Point’ is a generic description for the class of object represented by analog and binary inputs, outputs, and values either physical or virtual. All systems shall use this naming convention and process.

Any deviations from this process require prior approval of the GSA and/or their representative.

Point naming shall be consistent through system drawings, records, files and documents. Please reference the GSA Point Naming Convention for Building Management Systems for more information.

2.3.5 Minimum Point Lists

Designs for Building Control System and HVAC controllers are unique to every project. Designs can be influenced by budget, climate, system type, size of system, desired sequence of operations, existing infrastructure, and a multitude of other factors. As such, the equipment, level of control, sensors and sophistication of systems will vary greatly. Good system design and proper control sequence documentation will always clearly dictate the points in a BAS required to execute the control sequence.

The purpose of the “GSA Minimum Point List” is not to require additional equipment or sensors, but rather indicate the points that should be considered as value added monitoring points to be included in the Building Control System design and made accessible to third party systems.

Please reference GSA Minimum Point List for Building Systems for more information.

2.4 Digital Lighting Control

Digital lighting offers a means of controlling one of the largest utility cost centers in commercial buildings. Digital lighting control can accomplish load reduction, load shedding, demand response, daylight harvesting and data collection. Digital lighting can be as simple as scheduled lighting scenes or occupancy sensors or can be advanced control integrated into 3rd party systems for complex scenario control. Digital lighting control should be considered in any large building as it offers some of the best energy savings of any building system.

Requirements:

• Lighting system shall allow for time and date based scheduling for lighting control.

• Lighting systems shall allow for occupancy sensors to trigger occupancy timed lighting sequences.

• Lighting systems shall control to the fixture level.

• Lighting system shall provide a graphical based control platform and include historic usage.

• Lighting system should provide energy usage monitoring and reporting.

• Lighting system should be capable of daylight harvesting or utilizing natural light and artificial light together to provide the minimum lighting scenario, as required.

• Lighting systems should use industry standard open protocols to communicate between ballasts and panels. These open protocols include BACnet, Lon, or DALI.

• Lighting systems should allow for integration into plug load circuit control, offering an occupancy or schedule based circuit control.

• Lighting systems should be capable of override by software or hardware.

• Lighting systems installed in conference rooms should be capable of storing and recalling multiple lighting scenes, include scenes that override occupancy lighting for projection or video display. These scenes should be controlled by hardware or software commands.

• Lighting systems should be capable of load shedding and demand response. This can be either automated or manually triggered sequences that reduce the lighting energy load.

• Lighting system servers should be capable of running in virtual environments, specifically allowing communication between devices and servers to pass through wide area networks.

• Lighting system should be capable of notifications of ballast failures, maintenance requirements or other system alarms.

• Shade Control should be considered when utilizing digital lighting control, particularly when implementing daylight harvesting technologies.

• Occupancy sensing can be used by HVAC systems to control set points in areas for unoccupied setback. When lighting control systems are utilized with occupancy control, Integrated Sequences of Operations should be considered.

• Lighting control systems can be powerful tools for tenant pressure, when utilizing hoteling, consider integrating the hoteling schedule into the lighting control. Lighting scenarios can operate on the hoteling software schedule, discouraging “squatting” or pop in area use.

2.4.1 Shade Control

Shade control, often implemented as a function of the digital lighting control, is a system that allows for automated adjustments in natural light into spaces. The shade control system can be programmed to operate on a schedule or adjust dynamically to the lighting conditions present.

Introduction of natural light offers opportunities to lower the demand on artificial lighting and reducing energy consumption. Shade control should be strongly considered if using a digital lighting control system.

Requirements:

• Shade control shall be controlled by schedule, date or calendar.

• Shade control shall allow for overrides by software or hardware.

• Shade Control should consider area use case when programming shades and shade schedule. Office space should try to allow for daylight while limiting screen glare.

Conference space should allow for shades to utilize natural light or to dim light for presentations.

• Shade control should utilize daylight sensors to maximize natural light, when possible.

• When utilizing daylight sensors, shade control should require a minimum outdoor light threshold before lowering shades.

Considerations:

• Shades can be used as security means, minimizing visibility into areas after hours. This could be coordinated with the building security team.

• While natural light can minimize the lighting power load, the addition of solar heat should be considered in hot months, particularly for southern exposure windows.

2.5 Metering and Sub-Metering

One of the most important steps in reducing energy usage is understanding utility usage in a facility. Metering systems allow for precise monitoring of usage, allowing system owners to track, trend, and understand their usage.

2.5.1 Utility Metering

Utility metering tracks the large utility costs incurred in building operation.

Requirements:

• Main electric, water, steam, gas and oil use shall be metered, where applicable.

• Metering systems shall store metering data for a minimum of 90 days.

• Main electric, water, steam, gas and oil use shall be metered, where applicable per the

P100.

• Utility meter data shall be integrated into both ION EEM and the BAS, when possible.

• Metering graphics shall be created in the building BAS for ease of monitoring and reporting when integrated.

• Historical trending intervals for meter data shall be coordinated with building sequences and demand response programs to be used for verification and tracking of energy savings.

• Metering systems should store data for archives and annual comparison.

• Metering system data should be accessible by third party applications for analysis, alarming, and publishing.

• Compatibility of equipment - Advanced electric metering projects shall use ION brand meters or integration gateways to ensure full compatibility.

o GSA utilizes the ION EEM Enterprise Energy Management system to manage utility data across the portfolio. While an open protocol will be used in connecting the meters and software, advanced metering functions (such as waveform capture, remote reprogramming of instrumentation wiring and ratios, etc.) requires matching the software and meter brands for full compatibility.

o Meters shall use Modbus communication if ION EEM integration is required.

• GSA utilizes the Schneider ION Enterprise Energy Management metering system to manage utility feeds across multiple buildings. This information is valuable on a regional level, to understand the high-energy users and provide data to regional leadership.

Providing system owners, operations and maintenance engineers and building mangers access to this data can help building operators proactively manage their building and lower energy costs.

• Turndown ratios must be considered when specifying and installing meters based on the expected minimum and maximum flows of the service being measured.

• Independent metering systems or software shall not be used unless otherwise directed or required for a project.

2.5.2 Sub-metering

Beyond main utilities, individual cost centers can be segmented with sub-metering to paint a clearer picture of energy usage. Sub-metering should be designed with the end user in mind. Sub-metering provides a wealth of information but if that information is not monitored or utilized, sub-metering can be a costly expense with little return.

Requirements:

• Sub-Metering data shall be integrated into the existing BAS, lighting system or other user interface accessible by the property management and operations and maintenance teams.

Recommendations:

• Meters should be specified that do not require proprietary current transformers.

• Communication interfaces should be utilized instead of pulse outputs, whenever possible.

• Meters should be able to temporarily record meter data in the event communication to its historian database is disrupted. Meters should also be capable of syncing data with the server to avoid gaps in data quality.

• Sub metering systems should include these cost centers when applicable:

o Lighting o HVAC Equipment o Tenant Space (if multi-tenants or large overtime utility use expected) o Major Energy consuming equipment (IT Closets, Tenant equipment, etc.)

Considerations:

• Consider evaluating the use of multi-circuit meters in lieu of multiple individual meters when evaluating sub metering of multiple loads in a confined area.

• Consider using voltage output current transformers to avoid needing shorting blocks.

• Sub-metering should be strongly considered for Measurement and Verification (M&V) applications related to energy savings performance contracts and other energy based projects. This includes central plants (kW/ton), lighting/plug loads, cooling tower make-up/blowdown, major HVAC, etc.

• Ensure sufficient straight runs are available for applicable metering applications and meters are appropriately sized to the process being measured.

• Sub-metering is useful for measurement and verification (M&V) in energy savings performance contracts and other energy based projects. In cases where the sub-metering data is to be used for M&V careful coordination with the system installer should be made.

2.5.3 Automated Demand Response

Innovations in the power distribution grid allow buildings and the systems within to dynamically react to valuable utility data and load shed commands. By lowering the energy use when the demand, and therefore costs, are high alleviates the demand on the grid and the cost of the energy.

Requirements:

• Automated demand response sequences shall be developed with the input from Facilities Management & Services Programs Division Energy Branch, system owners and tenants.

• Demand response sequences shall not interfere with critical operation, IT equipment or any life safety requirements of a given space.

• Automated demand response shall be configurable by system owners to override in cases that permit peak loads.

• Automated demand response shall be commissioned to ensure that demand response sequences produce the expected load reduction.

• Automated demand response sequences shall be coordinated with local utility companies to ensure proper demand reduction, and to ensure the GSA received any incentives available.

Recommendations:

• Automated demand response sequences should be communicated with tenant agencies to clearly communicate any manner that tenant space will be affected by load shedding.

• Automated demand response should utilize lighting, HVAC and other power centers to allow for peak demand reduction.

• Automated demand response should be programmed to allow for multiple level demand response. This tiered programming will allow for low to no impact demand reduction, medium impact demand reduction and emergency level load reduction (in cases that utilities fear brown-outs).

Considerations:

• Automated demand response and smart grid technology is a newly blossoming field.

Careful communication should be made with GSA Facilities Management & Services Programs Division Energy Branch to ensure that any incentives for energy reduction from local utilities are accounted for and that method for trigger demand reduction are understood from both utility provider and system owner.

2.6 Digital Signage

Central Office FMSP is commissioning a 50-building proof of concept digital signage project which will create a standardized technical architecture, content development, and content management platform that can be deployed and operated in a secure, consistent, and cost effective manner. If a project intends to utilize digital signage, project teams should contact Mike Malane (mike.malane@gsa.gov).

2.7 Hoteling

Effective management of tenants and space utilization presents another unique way to save resources across a portfolio. These systems, in unison with mechanical and electrical building systems, cannot only provide efficiencies but can improve tenant satisfaction.

Hoteling systems allow for automated control of building populations and space sharing.

Implementing a system that can dynamically control population, and distribution of tenants can allow for a greater balance of resources in a smaller footprint. Hoteling systems should be considered when building populations are flexible and operations allow for a mobile tenant.

Requirements:

• Hoteling systems shall be coordinated with tenant agencies, building managers and operations & maintenance organizations to ensure the understanding of multiuse tenant space and how it affects the building operation plan (BOP).

Considerations:

• When utilizing a hoteling system, the information available on occupancy, space utilization and population density should be used to best manage the other building systems. This information may be connected directly to schedules of HVAC and lighting controls to ensure the systems are only occupied when spaces are reserved, or may be useful indicators to system operators of expected building population for a given day.

• If tenant space is flexible and reservations are required, building managers and operators should consider using the reservation system to “dynamically stack” the building. By consolidating the population into a select area, areas, wings or entire floors could be put into an “unoccupied” mode, reducing the energy use. This dynamic stacking requires flexible tenants and tenant spaces but offers great energy savings when fully deployed.

2.8 Occupancy Counting

Public buildings or offices that share spaces can have large fluctuations in the building population and these variances often go unnoticed by building systems. Deploying occupancy detection or people counting technology can help maximize building utilization, manage effective use of shared workspaces, and improve the operation of mechanical systems. Reporting energy use per person, for instance, can be a powerful way to engage the tenant and provide a way to relate the performance of a building to their daily interactions while inside. People counting can be accomplished by physical access control systems or passive sensor technologies placed at entries and exits. This technology should be considered when optimizing systems based on occupancy or when there is a plan to communicate building performance or energy savings to tenants through digital signage or other methods.

Recommendations:

• Occupancy counting systems should be configured to capture all entry and egress locations, excluding emergency exits. The data from these systems should be a live picture of the population inside a building.

• Occupancy counting systems should be designed and installed with methods of utilizing the data they create. This data could be useful for digital signage (normalizing energy usage per person), HVAC control, security or other building operations.

2.9 Native Power

Enterprise workspace is increasingly converged to IP network infrastructure. Power over Ethernet (POE) is one of the most widely deployed technologies to provide power to networked devices.

System contractors and designers shall consider utilizing POE if controls and edge devices can be purchased with PoE configurations, where the application presents itself and is life cycle cost effective. These PoE devices may be controllers, edge devices or sensors.

Requirements:

• When utilizing Native Power or Power over Ethernet devices, contractors shall coordinate with GSA IT to ensure properly sized and configured PoE switches and wiring are included in the project budget.

3 Other Smart Building Project Considerations

3.1 System Design

With all Smart Building Projects, as with all technology in general, the benefits of the systems are reliant on their use and maintenance. It is critical to consider the lifespan and end user of every system when designing and implementing and building system. Coordination with facility managers, operation and maintenance engineers and other parties invested in the technology should be considered early and often during design stages. Goals of the system use should be agreed upon by the project team for the building operators to have targets for building metrics.

3.2 Commissioning

Beyond design coordination, it is important to ensure that systems are commissioned as integrated systems as well as standalone systems. Commissioning agents should have a thorough understanding of the system integration and the fail-over sequences in cases that the integration is lost. These sequences should be tested including a test to ensure the failover and return-to-normal operations execute as expected.

3.3 Training

System training is crucial to the success of smart building systems and programs. Training on systems should cover day to day operation of the building systems as well as detailed system maintenance, administration and troubleshooting. This training should be recorded for future building operators to reference and re-train. Project teams should ensure that system training is budgeted for and that system turnover is well documented.

3.4 System Maintenance

Systems must be maintained to continue to provide reliable data to the users. Regular maintenance instructions should be explained to system owners and building managers. For complex systems, particularly building automation systems, service agreements must be included for regular upkeep and updates. System patches, clean up, backups and tuning must be included in these maintenance agreements to ensure the system continues to run as expected through the life span.