23 09 23.02.pdf

INSTALL REACT VII FACILITY, B9001 WWYK250063

SECTION 23 09 23.02 Page 1

SECTION 23 09 23.02

BACNET DIRECT DIGITAL CONTROL FOR HVAC AND OTHER BUILDING CONTROL SYSTEMS

11/15

PART 1 GENERAL

1.1 SUMMARY

Provide a complete Direct Digital Control (DDC) system, suitable for the control of the heating, ventilating and air conditioning (HVAC) and other building-level systems as specified and shown and in accordance with Section 23 09 13 INSTRUMENTATION AND CONTROL FOR HVAC.

The new DDC system shall be Honeywell or approved equal to allow seamless connection into the existing Honeywell base front end. The Temperature Control Contractor shall verify exact base front end with the COR before starting any work. Before the start of construction, the Temperature Control Contractor shall meet with the Base EMCs Supervisor to discuss recovery of existing working controls that are removed from the building.

All installed control systems shall be connected to the existing base wide Civil Engineering Community Of Interest Network Enclave (CE COINE). The control systems shall be programmed into the base wide Honeywell Enterprise Building Integrator (EBI) and front end graphics updated to reflect new work and control sequences. Contractor shall contact and coordinate connections with the CE IAM. All new and replacement building level controllers shall be Honeywell Comfort Point Open CPO-PC-6A.

1.1.1 System Requirements

Provide a system meeting the requirements of both Section 23 09 13 INSTRUMENTATION AND CONTROL FOR HVAC and this Section and with the following characteristics:

a. Except for Gateways, the control system must be an open implementation of BACnet technology using ASHRAE 135 and Fox as the communications protocols. The system must use standard ASHRAE 135 Objects and Properties. The system must use standard ASHRAE 135 Services exclusively for communication over the network. Gateways to packaged units must communicate with other DDC hardware using ASHRAE 135 or the Fox protocol exclusively and may communicate with packaged equipment using other protocols. The control system must be installed such that any two ASHRAE 135 devices on the internetwork can communicate using standard ASHRAE 135 Services.

b. Install and configure control hardware to provide ASHRAE 135 Objects and Properties as indicated and as needed to meet the requirements of this specification.

c. Use standard BACnet hardware and software exclusively for scheduling, trending, and communication with a front end (UMCS). Use standard BACnet Objects and services for alarming. Use the ASHRAE 135 protocol for all other building communication.

1.1.2 Verification of Specification Requirements

Review all specifications related to the control system installation and advise the Contracting Officer of any discrepancies before performing any

SECTION 23 09 23.02 Page 2 work. If Section 23 09 13 INSTRUMENTATION AND CONTROL FOR HVAC or any other Section referenced in this specification is not included in the project specifications advise the Contracting Officer and either obtain the missing Section or obtain Contracting Officer approval before performing any work.

1.2 REFERENCES

The publications listed below form a part of this specification to the extent referenced. The publications are referred to within the text by the basic designation only.

AMERICAN SOCIETY OF HEATING, REFRIGERATING AND AIR-CONDITIONING

ENGINEERS (ASHRAE)

ASHRAE 135 (2016; INT 1 2016; ERTA 1 2016) BACnet—A Data Communication Protocol for Building Automation and Control Networks

BACNET INTERNATIONAL (BTL)

BTL Guide (v.46; 2015) BACnet Testing Laboratory Implementation Guidelines

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE)

IEEE 802.3 (2015; CORR 2017) Ethernet

TELECOMMUNICATIONS INDUSTRY ASSOCIATION (TIA)

TIA-485 (1998a; R 2012) Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems

U.S. FEDERAL COMMUNICATIONS COMMISSION (FCC)

FCC Part 15 Radio Frequency Devices (47 CFR 15)

UNDERWRITERS LABORATORIES (UL)

UL 916 (2015) Standard for Energy Management Equipment

1.3 DEFINITIONS

For definitions related to this section, see Section 23 09 13

INSTRUMENTATION AND CONTROL FOR HVAC.

1.4 SUBMITTALS

Submittal requirements related to this Section are specified in Section

23 09 13 INSTRUMENTATION AND CONTROL FOR HVAC.

PART 2 PRODUCTS

All products used to meet this specification must meet the indicated requirements, but not all products specified here will be required by every project. All products must meet the requirements both Section 23 09 13 INSTRUMENTATION AND CONTROL FOR HVAC and this Section.

SECTION 23 09 23.02 Page 3

2.1 NETWORK HARDWARE

2.1.1 BACnet Router

All BACnet Routers must be BACnet/IP Routers and must perform layer 3 routing of ASHRAE 135 packets over an IP network in accordance with ASHRAE 135 Annex J and Clause 6. The router must provide the appropriate connection to the IP network and connections to one or more ASHRAE 135 MS/TP networks. Devices used as BACnet Routers must meet the requirements for DDC Hardware, devices used as BACnet routers must support the NM-RC-B

BIBB.

2.1.2 BACnet Gateways

In addition to the requirements for DDC Hardware, the BACnet Gateway must meet the following requirements:

a. It must perform bi-directional protocol translation from one non- ASHRAE 135 protocol to ASHRAE 135. BACnet Gateways must incorporate a network connection to an ASHRAE 135 network (either BACnet over IP in accordance with Annex J or MS/TP) and a separate connection appropriate for the non-ASHRAE 135 protocol and media.

b. It must retain its configuration after a power loss of an indefinite time, and must automatically return to their pre-power loss state once power is restored.

c. It must allow bi-directional mapping of data between the non-ASHRAE 135 protocol and Standard Objects as defined in ASHRAE 135. It must support the DS-RP-B BIBB for Objects requiring read access and the DS-WP-B BIBB for Objects requiring write access.

d. It must support the DS-COV-B BIBB.

Although Gateways must meet DDC Hardware requirements, they are not DDC Hardware and must not be used when DDC Hardware is required.

2.1.3 Ethernet Switch

Ethernet Switches must be managed switches and must autoconfigure between 10,100 and 1000 megabits per second (MBPS).

2.2 CONTROL NETWORK WIRING

a. BACnet MS/TP communications wiring must be in accordance with ASHRAE 135.

The wiring must use shielded, three wire (twisted-pair with reference) cable with characteristic impedance between 100 and 120 ohms.

Distributed capacitance between conductors must be less than 30 pF per foot.

b. Building Control Network Backbone IP Network must use Ethernet media.

Ethernet cables must be CAT-5e at a minimum and meet all requirements of IEEE 802.3.

SECTION 23 09 23.02 Page 4

2.3 DIRECT DIGITAL CONTROL (DDC) HARDWARE

2.3.1 General Requirements

All DDC Hardware must meet the following requirements:

a. It must be locally powered and must incorporate a light to indicate the device is receiving power.

b. It must conform to the BTL Guide

c. It must be BACnet Testing Laboratory (BTL) Listed.

d. The Manufacturer's Product Data submittal for each piece of DDC Hardware must include the Protocol Implementation Conformance Statement (PICS) for that hardware as specified in Section 23 09 13

INSTRUMENTATION AND CONTROL FOR HVAC.

e. It must communicate and be interoperable in accordance with ASHRAE 135 and have connections for BACnet IP or MS/TP control network wiring.

f. Other than devices controlling terminal units or functioning solely as a BACnet Router, it must support DS-COV-B, DS-RPM-A and DS-RPM-B BIBBs.

g. Devices supporting the DS-RP-A BIBB must also support the DS-COV-A BIBB.

h. Application programs, configuration settings and communication information must be stored in a manner such that they persist through loss of power:

(1) Application programs must persist regardless of the length of time power is lost.

(2) Configured settings must persist for any loss of power less than 2,500 hours.

(3) Communication information, including but not limited to COV subscriptions, event reporting destinations, Notification Class Object settings, and internal communication settings, must persist for any loss of power less than 2,500 hours.

i. Internal Clocks:

(1) Clocks in DDC Hardware incorporating a Clock must continue to function for 120 hours upon loss of power to the DDC Hardware.

(2) DDC Hardware incorporating a Clock must support the DM-TS-B or

DM-UTC-B BIBB.

j. It must have all functionality indicated and required to support the application (Sequence of Operation or portion thereof) in which it is used, including but not limited to providing Objects as specified and as indicated on the Points Schedule.

k. In addition to these general requirements and the DDC Hardware Input-Output (I/O) Function requirements, all DDC Hardware must also meet any additional requirements for the application in which it is used (e.g. scheduling, alarming, trending, etc.).

SECTION 23 09 23.02 Page 5

l. It must meet FCC Part 15 requirements and have UL 916 or equivalent safety listing.

m. Device must support Commandable Objects to support Override requirements as detailed in PART 3 EXECUTION.

n. User interfaces which allow for modification of Properties or settings must be password-protected.

o. Devices communicating BACnet MS/TP must meet the following requirements:

(1) Must have a configurable Max_Master Property.

(2) DDC Hardware other than hardware controlling a single terminal unit must have a configurable Max_Info_Frames Property.

(3) Must respond to any valid request within 50 msec with either the appropriate response or with a response of "Reply Postponed".

(4) Must use twisted pair with reference and shield (3-wire media) wiring, or twisted pair with shield (2-wire media) wiring and use half-wave rectification.

p. Devices communicating BACnet/IP must use UDP Port 0xBAC0. Devices with configurable UDP Ports must default to 0xBAC0.

q. All Device IDs, Network Numbers, and BACnet MAC addresses of devices must be fully configurable without limitation, except MS/TP MAC addresses may be limited by ASHRAE 135 requirements.

r. For programmable DDC Hardware, provide and license to the project site all programming software required to program the Hardware in accordance with Section 23 09 13 INSTRUMENTATION AND CONTROL FOR HVAC.

s. For programmable DDC Hardware, provide copies of the installed application programs (all software that is not common to every controller of the same manufacturer and model) as source code compatible with the supplied programming software in accordance with Section 23 09 13 INSTRUMENTATION AND CONTROL FOR HVAC. The submitted application program must be the complete application necessary for controller to function as installed and be sufficient to allow replacement of the installed controller with another controller of the same type.

2.3.2 Hardware Input-Output (I/O) Functions

DDC Hardware incorporating hardware input-output (I/O) functions must meet the following requirements:

2.3.2.1 Analog Inputs

DC Hardware analog inputs (AIs) must be implemented using ASHRAE 135 Analog Input Objects and perform analog to digital (A-to-D) conversion with a minimum resolution of 8 bits plus sign or better as needed to meet the accuracy requirements specified in Section 23 09 13. Signal conditioning including transient rejection must be provided for each analog input.

Analog inputs must be capable of being individually calibrated for zero and span. Calibration via software scaling performed as part of point configuration is acceptable. The AI must incorporate common mode noise

SECTION 23 09 23.02 Page 6 rejection of at least 50 dB from 0 to 100 Hz for differential inputs, and normal mode noise rejection of at least 20 dB at 60 Hz from a source impedance of 10,000 ohms.

2.3.2.2 Analog Outputs

DDC Hardware analog outputs (AOs) must be implemented using ASHRAE 135 Analog Output Objects and perform digital to analog (D-to-A) conversion with a minimum resolution of 8 bits plus sign, and output a signal with a range of 4-20 mAdc or 0-10 Vdc. Analog outputs must be capable of being individually calibrated for zero and span. Calibration via software scaling performed as part of point configuration is acceptable. DDC Hardware with Hand-Off-Auto (H-O-A) switches for analog outputs must provide for overriding the output to 0 percent and to 100 percent.

2.3.2.3 Binary Inputs

DDC Hardware binary inputs (BIs) must be implemented using ASHRAE 135 Binary Input Objects and accept contact closures and must ignore transients of less than 5 milli-second duration. Protection against a transient 50VAC must be provided.

2.3.2.4 Binary Outputs

DDC Hardware binary outputs (BOs) must be implemented using ASHRAE 135 Binary Output Objects and provide relay contact closures or triac outputs for momentary and maintained operation of output devices. DDC Hardware with H-O-A switches for binary outputs must provide for overriding the output open or closed.

2.3.2.4.1 Relay Contact Closures

Closures must have a minimum duration of 0.1 second. Relays must provide at least 180V of isolation. Electromagnetic interference suppression must be provided on all output lines to limit transients to 50 Vac. Minimum contact rating must be 0.5 amperes at 24 Vac.

2.3.2.4.2 Triac Outputs

Triac outputs must provide at least 180 V of isolation. Minimum contact rating must be 0.5 amperes at 24 Vac.

2.3.2.5 Pulse Accumulator

DDC Hardware pulse accumulators must be implemented using either an ASHRAE 135 Accumulator Object or an ASHRAE 135 Analog Value Object where the Present_Value is the totalized pulse count. Pulse accumulators must accept contact closures, ignore transients less than 5 msec duration, protect against transients of 50 VAC, and accept rates of at least 20 pulses per second.

2.3.2.6 ASHRAE 135 Objects for Hardware Inputs and Outputs

The requirements for use of ASHRAE 135 objects for hardware input and outputs includes devices where the hardware sensor or actuator is integral to the controller (e.g. a VAV box with integral damper actuator, a smart sensor, a VFD, etc.)

SECTION 23 09 23.02 Page 7

2.3.2.7 Integrated H-O-A Switches

Where integrated H-O-A switches are provided on hardware outputs, controller must provide means of monitoring position or status of H-O-A switch. This feedback may be provided via any valid BACnet method, including the use of proprietary Objects, Properties, or Services.

2.3.3 Local Display Panel (LDP)

The Local Display Panels (LDPs) must be DDC Hardware with a display and navigation buttons or a touch screen display, and must provide display and adjustment of ASHRAE 135 Properties as indicated on the Points Schedule and as specified. LDPs must be either BTL Listed as a B-OD, B-OWS, B-AWS, or be an integral part of another piece of DDC Hardware listed as a B-BC.

For LDPs listed as B-OWS or B-AWS, the hardware must be BTL listed and the product must come factory installed with all applications necessary for the device to function as an LDP.

The adjustment of values using display and navigation buttons must be password protected.

2.3.4 Expansion Modules and Tethered Hardware

A single piece of DDC Hardware may consist of a base unit and also:

a. An unlimited number of hardware expansion modules, where the individual hardware expansion modules are designed to directly connect, both mechanically and electrically, to the base unit hardware. The expansion modules must be commercially available as an optional add-on to the base unit.

b. A single piece of hardware connected (tethered) to a base unit by a single cable where the cable carries a proprietary protocol between the base unit and tethered hardware. The tethered hardware must not contain control logic and be commercially available as an optional add-on to the base unit as a single package.

Note that this restriction on tethered hardware does not apply to sensors or actuators using standard binary or analog signals (not a communications protocol); sensors or actuators using standard binary or analog signals are not considered part of the DDC Hardware.

Hardware capable of being installed stand-alone, or without a separate base unit, is DDC Hardware and must not be used as expansion modules or tethered hardware.

2.3.5 Supervisory Control Requirements

2.3.5.1 Alarm Generation Hardware

DDC Hardware used for alarm generation must meet the following requirements:

a. Device must support the AE-N-I-B BIBB.

b. The Recipient_List Property must be Writeable for all Notification Class Objects used for alarm generation.

c. It is preferred, but not required, that devices support the DM-OCD-B BIBB on all Notification Class Objects and Event Enrollment Objects, SECTION 23 09 23.02 Page 8 such that a front end BTL listed as a B-AWS may create or delete Notification Class Objects and Event Enrollment Objects. It is also preferred, but not required that devices supporting the DM-OCD-B BIBB accept any valid value as an initial value for properties of Notification Class Objects and Event Enrollment Objects. Note that there are additional requirements in the EXECUTION Part of this Section for devices which do not support the DM-OCD-B BIBB as specified.

d. Devices provided to meet the the requirements indicated under "Support for Future Alarm Generation" in the EXECUTION part of this specification must support the AE-N-E-B BIBB.

2.3.5.2 Trending Hardware

DDC Hardware used for collecting trend data must meet the following requirements:

a. Device must support Trend Log or Trend Log Multiple Objects.

b. Device must support the T-VMT-I-B BIBB.

c. Devices provided to meet the EXECUTION requirement for support of Future Trending must support the T-VMT-E-B BIBB.

d. The following properties of all Trend Log or Trend Log Multiple Objects must be present and Writeable:

Start_Time Stop_Time Log_DeviceObjectProperty Log Interval Log interval must support an interval of at least 60 minutes duration.

e. Trend Log Objects must support using Intrinsic Reporting to send a BUFFER_FULL event.

f. The device must have a Notification Class Object for the BUFFER_FULL event. The Recipient_List Property must be Writeable.

g. Devices must support values of at least 1,000 for Buffer_Size Properties.

h. It is preferred, but not required, that devices support the DM-OCD-B BIBB on all Trend Log Objects, such that a front end BTL listed as a A-AWS may create or delete Trend Log Objects. It is also preferred, but not required that devices supporting the DM-OCD-B BIBB accept any valid value as an initial value for properties of Trend Log Objects. Note that there are additional EXECUTION requirements for devices which do not support the DM-OCD-B BIBB as specified.

PART 3 EXECUTION

3.1 CONTROL SYSTEM INSTALLATION

3.1.1 Building Control Network (BCN)

Install the Building Control Network (BCN) as a single BACnet internetwork consisting of a single IP network as the BCN Backbone and zero or more BACnet MS/TP networks. Note that in some cases there may only be a single

SECTION 23 09 23.02 Page 9 device on the BCN Backbone.

Except for the IP Network and as permitted for the non-BACnet side of Gateways, use exclusively ASHRAE 135 networks.

3.1.1.1 Building Control Network IP Backbone

Install IP Network Cabling in conduit. Install Ethernet Switches in lockable enclosures. Install the Building Control Network (BCN) IP Backbone such that it is available at the Facility Point of Connection (FPOC) location. Coordinate the exact location with the COR. When the FPOC location is a room number, provide sufficient additional media to ensure that the Building Control Network (BCN) IP Backbone can be extended to any location in the room.

Use UDP port 0xBAC0 for all BACnet traffic on the IP network.

3.1.1.2 BACnet MS/TP Networks

When using MS/TP, provide MS/TP networks in accordance with ASHRAE 135 and in accordance with the ASHRAE 135 figure "Mixed Devices on 3-Conductor Cable with Shield" (Figure 9-1.4 in the 2012 version of ASHRAE 135).

Ground the shield at the BACnet Router and at no other point. Ground the reference wire at the BACnet Router through a 100 ohm resistor and do not ground it at any other point. In addition:

a. Provide each segment in a doubly terminated bus topology in accordance with TIA-485.

b. Provide each segment with 2 sets of network bias resistors in accordance with ASHRAE 135, with one set of resistors at each end of the MS/TP network.

c. Use 3 wire (twisted pair and reference) with shield media for all MS/TP media installed inside. Use fiber optic isolation in accordance with ASHRAE 135 for all MS/TP media installed outside buildings, or between multiple buildings.

d. For 18 AWG cable, use segments with a maximum length of 4000 ft. When using greater distances or different wire gauges comply with the electrical specifications of TIA-485.

e. For each controller that does not use the reference wire provide transient suppression at the network connection of the controller if the controller itself does not incorporate transient suppression.

f. Install no more than 32 devices on each MS/TP segment. Do not use MS/TP to MS/TP routers.

g. For BACnet Routers, configure the MS/TP MAC address to 0. Assign MAC Addresses to other devices consecutively beginning at 1, with no gaps.

h. Configure the Max_Master Property of all devices to be 31.

3.1.1.3 Building Control Network (BCN) Installation

Provide a building control network meeting the following requirements:

a. Install all DDC Hardware connected to the Building Control Network.

SECTION 23 09 23.02 Page 10

b. Where multiple pieces of DDC Hardware are used to execute one sequence, install all DDC Hardware executing that sequence on a single MS/TP network dedicated to that sequence.

c. Traffic between BACnet networks must be exclusively via BACnet routers.

3.1.2 DDC Hardware

Install all DDC Hardware that connects to an IP network in lockable enclosure. Install other DDC Hardware that is not in suspended ceilings in lockable enclosures. For all DDC hardware with a user interface, coordinate with site to determine proper passwords and configure passwords into device.

a. Except for zone sensors (thermostats), install all Tethered Hardware within 6 feet of its base unit.

b. Install and configure all BTL-Listed devices in a manner consistent with their BTL Listing such that the device as provided still meets all requirements necessary for its BTL Listing.

c. Install and configure all BTL-Listed devices in a manner consistent with the BTL Device Implementation Guidelines such that the device as provided meets all those Guidelines.

3.1.2.1 Device Identifiers, Network Addresses, and IP addresses

a. Do not use any Device Identifier or Network Number already used by another BACnet system at the project site. Coordinate Device IDs and Network Numbers with the installation. The installation POC is the Honeywell.

b. Coordinate device IP addresses with installation. The installation POC is the 72 ABW/SC.

3.1.2.2 ASHRAE 135 Object Name Property and Object Description Property

Configure the Object_Names and Object_Descriptions properties of all ASHRAE 135 Objects (including Device Objects) as indicated on the Points Schedule (Point Name and Point Description) and as specified. At a minimum:

a. Except for DDC Hardware controlling a single terminal unit, configure the Object_Name and Object_Description properties of all Objects (including Device Objects) as indicated on the Points Schedule and as specified.

b. In DDC Hardware controlling a single terminal unit, configure the Device Object_Name and Device Object_Description as indicated on the Points Schedule and as specified.

When Points Schedule entries exceed the length limitations in the device, notify the COR and provide recommended alternatives for approval.

3.1.2.3 Hand-Off-Auto (H-O-A) Switches

Provide Hand-Off-Auto (H-O-A) switches as specified and as indicated on the Points Schedule. Provide H-O-A switches that are integral to the controller hardware, an external device co-located with (in the same enclosure as) the controller, integral to the controlled equipment, or an external device

SECTION 23 09 23.02 Page 11 co-located with (in the same enclosure as) the controlled equipment.

a. For H-O-A switches integral to DDC Hardware, meet the requirements specified in paragraph DIRECT DIGITAL CONTROL (DDC) HARDWARE.

b. For external H-O-A switches used for binary outputs, provide for overriding the output open or closed.

c. For eternal H-O-A switches used for analog outputs, provide for overriding through the range of 0 percent to 100 percent.

3.1.2.4 Local Display Panels

Provide LDPs to display and override values of points in ASHRAE 135 Object Properties as indicated on the Points Schedule. Install LDPs displaying points for anything other than a terminal unit in the same room as the equipment. Install LDPs displaying points for only terminal units in a mechanical room central to the group of terminal units it serves. For LDPs using WriteProperty to commandable objects to implement an override, write values with priority 10.

3.1.2.5 MS/TP Slave Devices

Configure all MS/TP devices as Master devices. Do not configure any devices to act as slave devices.

3.1.2.6 Change of Value (COV) and Read Property

a. To the greatest extent possible, configure all devices to support the SubscribeCOV service (the DS-COV-B BIBB). At a minimum, all devices supporting the DS-RP-B BIBB, other than devices controlling only a single terminal unit, must be configured to support the DS-COV-B BIBB.

b. Whenever supported by the server side, configure client devices to use the DS-COV-A BIBB.

3.1.2.7 Engineering Units

Configure devices to use English (Inch-Pound) engineering units as follows:

a. Temperature in degrees F

b. Air or natural gas flows in cubic feet per minute (CFM)

c. Water in gallons per minute (GPM)

d. Steam flow in pounds per hour (pph)

e. Differential Air pressures in inches of water column (IWC)

f. Water, steam, and natural gas pressures in PSI

g. Enthalpy in BTU/lb

h. Heating and cooling energy in MBTU (1MBTU = 1,000,000 BTU))

i. Cooling load in tons (1 ton = 12,000 BTU/hour)

j. Heating load in MBTU/hour (1MBTU = 1,000,000 BTU)

SECTION 23 09 23.02 Page 12

k. Electrical Power: kilowatts (kW)

l. Electrical Energy: kilowatt-hours (kWh)

3.1.2.8 Occupancy Modes

Use the following correspondence between value and occupancy mode whenever an occupancy state or value is required:

a. OCCUPIED mode: a value of one

b. UNOCCUPIED mode: a value of two

c. WARM-UP/COOL-DOWN (PRE-OCCUPANCY) mode: a value of three

Note that elsewhere in this Section the Schedule Object is required to also support a value of four, which is reserved for future use. Also note that the behavior of a system in each of these occupancy modes is indicated in the sequence of operation for the system.

3.1.2.9 Use of BACnet Objects

Use only standard non-proprietary ASHRAE 135 Objects and services to accomplish the project scope of work as follows:

a. Use Analog Input or Analog Output Objects for all analog hardware I/O.

Do not use Analog Value Object for analog hardware I/O) .

b. Use Binary Input or Binary Output Objects for all binary hardware I/O.

Do not use Binary Value Objects for binary hardware I/O.

c. Use Analog Value Objects for analog setpoints.

d. Use Accumulator Objects or Analog Value Objects for pulse inputs.

e. For occupancy modes, use Multistate Value Objects and the correspondence between value and occupancy mode specified in paragraph

OCCUPANCY MODES.

f. Use Trend Log Objects or Trend Log Multiple Objects for all trending and Notification Class Objects for trend log upload. Use a combination of Event Enrollment Objects. Intrinsic Alarming, and Notification Class Objects for alarm generation.

g. For all other points shown on the Points Schedule as requiring an ASHRAE 135 Object, use the Object type shown on the Points Schedule or, if no Object Type is shown, use a standard Object appropriate to the point.

3.1.2.10 Use of Standard BACnet Services

Except as noted in this paragraph, for all DDC Hardware use Standard BACnet Services as defined in this specification (which excludes some ASHRAE 135 services) exclusively for application control functionality and communication.

DDC Hardware that cannot meet this requirement may use non-standard services provided they can provide identical functionality using Standard

SECTION 23 09 23.02 Page 13

BACnet Services when communicating with BACnet devices from a different vendor. When implementing non-standard services, document all non-standard services in the DDC Hardware Schedule as specified and as specified in Section 23 09 13 INSTRUMENTATION AND CONTROL FOR HVAC.

3.1.2.11 Device Application Configuration

a. For every property, setting or value shown on the Points Schedule or otherwise indicated as Configurable, provide a value that is retained through loss of power and can be changed via one or more of:

(1) BACnet services (including proprietary services)

(2) Hardware settings on the device

b. For every property, setting or value shown on the Points Schedule or otherwise indicated as Operator Configurable, provide a value that is retained through loss of power and can be changed via one or more of:

(1) A Writeable Property of a standard BACnet Object

(2) A Property of a standard BACnet Object that is Writeable when Out_Of_Service is TRUE and Out_Of_Service is Writeable.

3.1.3 Scheduling, Alarming, Trending, and Overrides

3.1.3.1 Scheduling

Configure schedules in BACnet Scheduling Objects to schedule systems as indicated on the Points Schedule and as specified using the indicated correspondence between value and occupancy mode. If no devices supports both the SCHED-E-B and DM-OCD-B BIBBS for Schedule Objects, provide 5 blank Schedule Objects in DDC Hardware BTL listed as B-BCs and supporting the SCHED-E-B BIBB for later use by the site.

Provide a separate schedule for each AHU including it's associated Terminal Units and for each stand-alone Terminal Unit (those not dependent upon AHU service) or group of stand-alone Terminal Units acting according to a common schedule.

3.1.3.2 Configuration Alarm Generation

Configure alarm generation as indicated on the Points Schedule and as specified using Intrinsic Alarming in accordance with ASHRAE 135 or Algorithmic Alarming in accordance with ASHRAE 135. Alarm generation must meet the following requirements:

a. Send alarm events as Alarms (not Events).

b. Use the ConfirmedNotification Service for alarm events.

c. For alarm generation, support two priority levels for alarms: critical and non-critical. Configure the Priority of Notification Class Objects to use Priority 112 for critical and 224 for non-critical alarms.

d. Number of Notification Class Objects for Alarm Generation:

(1) If the device implements non-critical alarms, or if any Object in the device supports Intrinsic Alarms, then provide a single

SECTION 23 09 23.02 Page 14

Notification Class Object specifically for (shared by) all non-critical alarms.

(2) If the device implements critical alarms, provide a single Notification Class Object specifically for (shared by) all critical alarms.

(3) If the device implements both critical and non-critical alarms, provide both Notification Class Objects (one for critical, one for non-critical).

(4) If the device controls equipment other than a single terminal unit, provide both Notification Class Objects (one for critical, one for non-critical) even if no alarm generation is required at time of installation.

e. For all intrinsic alarms configure the Limit_Enable Property to set both HighLimitEnable and LowLimitEnable to TRUE. If the specified alarm conditions are for a single-sided alarm (only High_Limit used or only Low_Limit used) assign a value to the unused limit such that the unused alarm condition will not occur.

f. For all objects supporting intrinsic alarming, even if no alarm generation is required during installation, configure the following Properties as follows:

(1) Notification_Class to point to the non-Critical Notification Class Object in that device.

(2) Limit_Enable to enable both the HighLimitEnable and LowLimitEnable

(3) Notify_Type to Alarm

g. Use of alarm generation types:

(1) Only use algorithmic alarm generation when intrinsic alarm generation is not supported by the device or object, or when the specific alarm conditions cannot be implemented using intrinsic alarm generation.

(2) Only use remote alarm generation when the alarm cannot be generated using intrinsic or local algorithmic alarm generation on the device containing the referenced property. If remote alarm generation is used, use the same DDC Hardware for all remote alarm generation within a single sequence.

3.1.3.3 Support for Future Alarm Generation

For every piece of DDC Hardware, support future alarm generation capabilities by supporting either intrinsic or additional algorithmic alarming. Provide one of the following:

a. Support intrinsic alarming for every Object used by the application in that device.

b. Support additional Event_Enrollment Objects. For DDC hardware controlling a single terminal unit, support at least one additional object. Otherwise, support at least 4 additional Objects. Support additional Event_Enrollment Objects via one of the following:

SECTION 23 09 23.02 Page 15

(1) Provide unused Event_Enrollment Objects on that device.

(2) Support the DM-OCD-B BIBB and the creation of sufficient Event_Enrollment Objects on that device.

(3) Provide one or more devices in the IP network that support the AE-N-E-B BIBB and have unused Event_Enrollment Objects.

(4) Provide one or more devices on the IP network that support the AE-N-E-B BIBB, the DM-OCD-B BIBB, and the creation of sufficient Event_Enrollment Objects.

The total number of Event_Enrollment Objects required by the project is the sum of the individual device requirements, and the distribution of Event_ Enrollment Objects among devices is not further restricted. (Note this allows a single device to contain many Event_Enrollment Objects satisfying the requirements for multiple devices.)

3.1.3.4 Trend Log Configuration

a. Configure trends in Trend Log or Trend Log Multiple Objects as indicated on the Points Schedule and as specified.

b. Configure all trend logs (including any provided to support future trends) to save data on regular intervals using the BUFFER_FULL event to request trend upload from the front end.

c. Configure Trend Log Objects with a minimum Buffer_Size property value of 1,000 and Trend Log Multiple Objects with a minimum Buffer_Size property value of 1,000 per point trended (for example, a Trend Log Multiple Object used to trend 3 points must have a Buffer_Size Property value of at least 3,000).

d. Configure a Notification Class Object in devices doing trending (including devices supporting future trends) to handle the BUFFER_FULL event.

e. When possible, trend each point using an Object in the device containing the point. When it is necessary to trend using a an Object in another device, all trends not on the same Device as the Object being trended must be on a singe device (i.e. all Trend Log and Trend Log Multiple Objects used for remote trending within a sequence must be on the same device).

f. For each trend log, including any trend logs provided to support future trending, configure the following properties as specified:

(1) Logging_Type: Set to Polling

(2) Stop_When_Full: Set to Wrap Around

(3) Buffer_Size: Set to 400 or greater.

(4) Notification_Threshold: Set to 90 percent of full

(5) Notification_Class: Set to the Notification Class Object in that device

SECTION 23 09 23.02 Page 16

(6) Event_Enable: Set to TRUE

(7) Log_Interval: Set to 15 minutes.

g. Future Trending support. Provide support for future trending:

(1) Provide one or more devices on the Building Control Network Backbone IP network which support both the T-VMT-E-B and DM-OCD-B BIBBs for Trend Log Objects. Provide sufficient devices to support the creation of at least one additional Trend Log Object for every terminal unit plus 4 additional Trend Log Objects for every non-terminal unit.

(2) Provide one additional Trend Log Object for every terminal unit plus 4 additional Trend Log Objects for every non-terminal unit in one or more devices on the Building Control Network Backbone IP network that support the T-VMT-E-B BIBB for later use by the site.

(3) A combination of these two methods is permitted provided the total required number of Trend Log Objects is met.

3.1.3.5 Overrides

Provide an override for each point shown on the Points Schedule as requiring an override.

Unless otherwise approved, provide Commandable Objects to support all Overrides in Framework Supervisory Gateway DDC Hardware. With specific approval from the contracting officer, Overrides for points which are not hardware outputs and which are in DDC hardware controlling a single terminal unit may support overrides via an additional Object provided for the override. No other means of implementing Overrides may be used.

a. Where Commandable Objects are used, ensure that WriteProperty service requests with a Priority of 10 or less take precedence over the SEQUENCE VALUE and that WriteProperty service request with a priority of 11 or more have a lower precedence than the SEQUENCE VALUE.

b. For devices implementing overrides via additional Objects, provide Objects which are NOT Written to as part of the normal Sequence of Operations and are Writeable when Out_Of_Service is TRUE and Out_Of_Service is Writeable. Use this point as an Override of the normal value when Out_Of_Service is TRUE and the normal value otherwise. Note these Objects may be modified as part of the sequence via local processes, but must not be modified by local processes when Out_Of_Service is TRUE.

3.1.4 BACnet Gateways

The requirements in this paragraph do not permit the installation of hardware not meeting the other requirements of this section. All control hardware installed under this project must meet the requirements of this specification, including control hardware provided as part of a package unit or as part of equipment specified under another section. Only use gateways to connect to pre-existing control devices.

Provide BACnet Gateways to non-BACnet control hardware as required to connect existing non-BACnet packaged units and in accordance with the following:

SECTION 23 09 23.02 Page 17

a. Each gateway must communicate with and perform protocol translation for non-BACnet control hardware controlling one and only one package unit.

b. Connect one network port on the gateway to the Building Control Backbone IP Network or to a BACnet MS/TP network and the other port to the single piece of controlled equipment.

c. Configure gateways to map writeable data points in the controlled equipment to Writeable Properties of Standard Objects as indicated in the Points Schedule and as specified.

d. Configure gateway to map readable data points in the controlled equipment to Readable Properties of Standard Objects as indicated in the Points Schedule and as specified.

e. Configure gateway to support the DS-COV-B BIBB for all points mapped to BACnet Objects.

f. Do not use non-BACnet control hardware for controlling built-up units or any other equipment that was not furnished with factory-installed controls.

g. Do not use non-BACnet control hardware for system scheduling functions.

h. Non-BACnet network wiring connecting the gateway to the package unit must not exceed 10 feet in length and must connect to exactly two devices: the controlled equipment (packaged unit) and the gateway.

3.2 SUBITTED REQUIRED DOCUMENTS

3.2.1 HVAC Controls contractor to provide complete HVAC system controls schematic for review and approval to include all equipment, sensors and major controllers. Provide Sequence of Operation for all HVAC equipment and modes of operation as indicated on the drawings. Provide Points Chart for all sensors, input and output.

3.3 TEST REPORT

3.3.1 HVAC Controls contractor to provide a final report indicating all points, equipment and sequences are working properly for a complete and operational HVAC controls system.

-- End of Section --