Attachment_D_-_GSA_R8_BAS_Technology_Implementation_Guide.pdf

United States of America General Services Administration

GSA R8 BAS Technology Implementation Guide

BAS Technology Implementation Guide

GSA Region 8 requires BAS providers (contractors, vendors) to design, build, configure, and implement technology using a specified architecture that meshes with GSA processes and procedures, allowing for interoperability, scalability, and high performance. This document is intended to assist the BAS provider in understanding GSA Standards and Specifications in a brief, illustrated overview. All requirements noted here are covered in detail in the GSA Standards and Specifications.

Topics:

• Overall Architecture

• BACnet

• Network Architecture

• Device & Object Naming Standard

• Device Schedule

• Object & Functionality Organization

• Integration

• Workflow

Overall Architecture

The BAS architecture is broken up into layers:

• Control Layer: comprised of devices that host all I/O and all control logic required to control equipment; this layer also includes protocol routers

• Integration Layer: comprised of gateways employing drivers to integrate legacy systems

• Enterprise Layer: comprised of data-center-based server software hosting GUI and BAS maintenance tools

• Historian Layer: comprised of consolidated data repository for archived data

Figure 2.1: Architecture pyramid

BACnet

All new devices on the Control Layer shall be native-BACnet. This is intended to provide full interoperability on the Control Layer without the need for integration gateways or drivers. The BAS provider is responsible for delivering and deploying BACnet devices that successfully join the BACnet internetwork without errors or communications issues. GSA manages IP and BACnet network configuration parameters:

• IP address, subnet mask, default gateway

• UDP port

• BACnet Network Number

• BACnet Device ID

• BACnet MS/TP MAC address

• BBMD functionality

These parameters are managed by GSA, and shall not be assigned ad hoc.

Any device proposed or submitted for use on GSA property shall be reviewed by a GSA technical engineer. The BAS provider must provide the technical engineer with adequate information to assess the device in terms of functionality, security, applicability, and ultimate suitability for use in GSA buildings/facilities. One important document is the BACnet PICS. No BACnet device will be permitted without a PICS. The other important item is BTL Certification. GSA prefers devices that are BTL-certified, and requires it in the specification. However, exceptions of BTL-certification can be made at the discretion of the reviewing GSA technical engineer.

All devices shall be BACnet, including any I/O or remote I/O expansion devices.

BACnet devices have fields for Device Object Name, Location, Description, Vendor Name, Vendor

Identifier, Model Name, Firmware Revision, and Application Software Revision. These fields shall be completed wherever possible. Having this information makes managing devices easier for BAS administrators.

BACnet objects have fields for Object Name, Object Type, Description, Device Type, and Units. These fields shall be completed accurately. The Units field shall be completed with standard BACnet units to ensure that the units will be recognized by the BACnet Client. This makes it simple for the technician, the technical engineer, the integrator, and the BACnet Client user to identify and understand the objects. (These features are part of what makes BACnet so undeniably superior to other protocols such as LonWorks or Modbus.)

Figure 3.1: BTL & BACnet logos

Network Architecture

The network architecture model is BACnet/IP-based for major equipment controllers, and BACnet

MS/TP-based for small equipment.

• Major equipment refers to central plant equipment, multi-zone AHUs and AHUs serving terminal units, central lighting panels, etc.

• Small equipment refers to FCU, VAV, CV, FTU, VRV, VV terminal units, single-zone AHUs, single-zone RTUs, VFDs, chillers, boilers, room or area lighting controllers, etc.

• If you are not sure if a device should be BACnet/IP or BACnet MS/TP, check with GSA

The network strategy allows for approximately 30 devices per MS/TP network. It is preferred that

MS/TP networks do not run between floors. Ideally the MS/TP network should be modeled after the equipment arrangement:

Figure 4.1: Typical equipment arrangement

Figure 4.2: Matching network arrangement

BACnet/IP devices shall be connected to the existing GSA IP network, and not on an ad hoc network.

BACnet/IP routers shall be located on each floor or area allowing any MS/TP devices on that floor or area to be connected. The BACnet/IP router may be a major equipment controller, such as an AHU controller in the example in Figure 4.2. The overall network riser should resemble Figure 5.1 below:

Figure 5.1: BACnet/IP routers on each floor serving small local BACnet MS/TP networks

BAS providers and installers are expected to immediately surrender all access account credentials for every device when the device is added to the network, and at any time they are requested by GSA. This includes all user, admin, and backdoor accounts and passwords. GSA will assume user management as early as possible in the process to ensure security of the system. This may include creating new individual accounts for BAS provider technicians that are limited in some ways. Of course, technician access will be maintained in a manner that will allow for the completion of the project, but access may be restricted beyond those requirements.

Device & Object Naming Standard

The intent of the Device & Object Naming Standard is to standardize the names of all system devices and objects in a manner that enables system users, data clients, and technicians to instantly recognize and understand devices and objects. The naming model is simple:

Figure 6.1: Object Naming Model

All devices and objects shall be named according to the GSA Device & Object Naming Standard. This means that each and every device will have a name, and each and every object will have a name. In

BACnet devices, the Device Object Name shall use this standardized format.

Objects that require standardized names:

• Device Object Name

• Control objects (points)

• Schedules

• Trend Logs

• Notification Classes

• Any device or object that can be discovered using BACnet services

Device and object naming shall be submitted for approval prior to implementation. Approval does not absolve the BAS provider of responsibility for fixing any missed mistakes, but it does prevent the BAS provider from having to re-do an entire project because they didn’t follow the process outlined in the specifications and standards documents.

Specifics on the Object Naming Model, as well as standardized object names, can be found in the Device

& Object Naming Standard document.

Figure 6.2: GSA R8 BAS Object Naming Standard – example page

Device Schedule

During the submittal phase of each project, a list of devices called the Device Schedule must be submitted using the template provided by GSA. This document makes it simple for the technical engineer to:

• Understand the riser diagram (also required)

• Assign network configuration parameters (assigned by GSA)

• Catalog and track active devices

• Manage networks (both IP and BACnet)

Instructions for completing the Device Schedule are available and recommended to make completing it easier.

Figure 7.1: Device Schedule detail – BAS provider section

Figure 7.2: Device Schedule detail – GSA technical engineer section

Object & Functionality Organization

Where objects reside is important to the scalability and futureproofing of an BAS installation. The following outlines the proper locations where each type of object or function shall be implemented:

• Control Layer (in the native-BACnet controllers):

o I/O support o Control Objects (points, both physical and virtual) o Control Logic (programming of any kind) o Equipment Schedules o Trend Logs o Alarms/Events o Notification Classes o Local UI (if required)

• Integration Layer (in the integration appliance in the building):

o Legacy Control Objects (point mapping) o Equipment Schedules for legacy system o Trend Logs for legacy system o Alarms/Events for legacy system o Control Logic to support legacy system o Local UI (if required)

• Enterprise Layer (in the Data Center):

o BACnet Client software o Configuration/Programming Tools o Graphical User Interface (GUI) o BACnet Holiday Calendar o Trend Data Visualization o Alarm/Event Management

• Historian Layer (in the Data Center):

o Long-term Trend Data Archive o API for data sharing

The important part for most installations is the Control Layer: By placing these items in the local BAS controller (a BACnet device), these items can be discovered and effortlessly imported unedited to whatever BACnet Client is being used, providing flexibility for the organization on the Enterprise and

Historian layers. The organization can select different BACnet Client software without having to replace integration devices or recreate code/functionality that was living on the Integration or Enterprise Layers.

The locations for objects and functions are also outlined in Figure 2.1.

Integration

The Integration Layer has a special purpose for the organization: To provide interoperability with legacy systems that will not be replaced immediately. In general, integration devices will not be required or permitted in new construction; GSA obtains connectivity and interoperability using BACnet/IP, and does not wish to add extra devices that will increase maintenance and management costs.

Integration devices, such as gateways, are permitted in new construction only in circumstances where

GSA pre-approves the use of the integration device and is made fully aware of the implications. This approval should be obtained in the proposal process to avoid cost to the BAS provider during project execution. The specification bans the use of gateways without explicit, written approval, and this requirement stands after contract award regardless of what the proposal states.

In cases where integration is permitted or is being used to connect legacy devices, all of the other standards and specifications still apply: Devices and objects must be named according to the Device &

Object Naming Standard, network guidelines must be followed, and documentation must be complete.

Any integration device should mirror all devices and control objects to virtual BACnet devices and objects to facilitate BACnet interoperability with the integrated system. All read/write functionality, as well as other special functionality, must be duplicated in the integration device to facilitate full operational capability from any BACnet Advanced WorkStation (B-AWS) Client.

GSA prefers to avoid gateways for several reasons: Gateways can create: pockets of proprietary systems where competition and futureproofing are threatened, bottlenecks that degrade system performance, and areas of limited functionality translation. Gateways generally do not translate all of the features of the native protocol to BACnet, creating the need for the organization to maintain multiple tools/user interfaces to operate the system. GSA intends to avoid this situation.

Figure 9.1: BACnet vs. Gateway – bottleneck issue

For all BAS products, BACnet or otherwise, if integration plug-ins are available for the Enterprise Layer user interface that provide tools for the BAS administrator and/or BAS technicians, this is preferred. The organization seeks to limit the number of product tools and platforms that need to be maintained and for technicians to be trained to use.

Workflow

The outcome expected from each building automation project is easier to achieve when an organized process is followed. The process:

• Project RFP/RFQ is posted

• Vendors review requirements and develop proposal that embodies the goals and intent of the organization; proposal includes plenty of product info

• GSA reviews proposals and selects a vendor based on the merits of the proposal and cost

• Vendor submits detailed design of proposed solution; submittal includes:

o Technical information and manuals for all proposed products (including PICS) o Device Schedule on template provided & RFI for network config info o Detailed riser diagram o Proposed device and object names & RFI for approval by GSA o Control diagrams that include device and object naming

• Vendor does not proceed until submittal has been reviewed and approved; any costs incurred by vendor prior to approval are at the vendor’s risk

• GSA technical engineer reviews design submittal, returns comments, and assigns network config info

• Design submittal is approved by GSA

• Project is executed

• GSA technical engineer checks for adherence to standards and specifications:

o Network configuration & architecture o Device naming & other info (description, location, etc.)

o Object naming & other info (description, units, etc.)

o User access & security

• Punchlist is created by GSA technical engineer & addressed by vendor

• All initial punchlist items are resolved by vendor

• Project commissioning is performed (point-to-point, functional performance testing) o Vendor cooperates with Cx contractor

• As-built documentation is submitted for approval

• As-built documentation is approved by GSA

• Customer training is performed

• When all issues are resolved, two-year warranty begins

• Warranty items are identified, and vendor resolves them

• Warranty period ends

Conclusion

The standards, specifications, and workflow process presented here provide a framework allowing GSA and vendors to work together efficiently to design and implement interoperable, secure, scalable BAS systems that will serve the organization into the future.