UFC 3-410-02 Direct Digital Control for HVAC Other.pdf

UFC 3-410-02

18 July 2018

Change 2, 12 April 2021

UNIFIED FACILITIES CRITERIA (UFC)

APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED

DIRECT DIGITAL CONTROL FOR

HVAC AND OTHER BUILDING

CONTROL SYSTEMS

DIRECT DIGITAL CONTROL FOR HVAC AND OTHER BUILDING CONTROL

SYSTEMS

Any copyrighted material included in this UFC is identified at its point of use.

Use of the copyrighted material apart from this UFC must have the permission of the copyright holder.

Indicate the preparing activity beside the Service responsible for preparing the document.

U.S. ARMY CORPS OF ENGINEERS \1\ (Preparing Activity) /1/

NAVAL FACILITIES ENGINEERING COMMAND \1\ /1/

AIR FORCE CIVIL ENGINEER CENTER

Record of Changes (changes are indicated by \1\ ... /1/)

Change No. Date Location 1 2 March 2020 Changed Preparing Activity from Navy to Army.

Added paragraph 2-4 USE OF PROPRIETARY NETWORKS, to accommodate new requirements for an exception to the use of open protocols within specific system types when certain criteria are met.

2 1 April 2021 Changed “UFC 3-401-01” to UFC 3-470-01” in paragraphs 1-2.1.3 and 1-3.2.3. Changed “APPENDIX A” to “APPENDIX D” in paragraph 5-4.2. Deleted first sentence of paragraph 6-6.1.

This UFC supersedes UFC 3-410-02, dated 5 2012.

FOREWORD

The Unified Facilities Criteria (UFC) system is prescribed by MIL-STD 3007 and provides planning, design, construction, sustainment, restoration, and modernization criteria, and applies to the Military Departments, the Defense Agencies, and the DoD Field Activities in accordance with USD (AT&L) Memorandum dated 29 May 2002. UFC will be used for all DoD projects and work for other customers where appropriate. All construction outside of the United States is also governed by Status of Forces Agreements (SOFA), Host Nation Funded Construction Agreements (HNFA), and in some instances, Bilateral Infrastructure Agreements (BIA.)

Therefore, the acquisition team must ensure compliance with the most stringent of the UFC, the SOFA, the HNFA, and the BIA, as applicable.

UFC are living documents and will be periodically reviewed, updated, and made available to users as part of the Services’ responsibility for providing technical criteria for military construction. Headquarters, U.S. Army Corps of Engineers (HQUSACE), Naval Facilities Engineering Command (NAVFAC), and Air Force Civil Engineer Center (AFCEC) are responsible for administration of the UFC system. Defense agencies should contact the preparing service for document interpretation and improvements. Technical content of UFC is the responsibility of the cognizant DoD working group. Recommended changes with supporting rationale should be sent to the respective service proponent office by the following electronic form: Criteria Change Request. The form is also accessible from the Internet sites listed below.

UFC are effective upon issuance and are distributed only in electronic media from the following source:

• Whole Building Design Guide web site http://dod.wbdg.org/.

Refer to UFC 1-200-01, DoD Building Code (General Building Requirements), for implementation of new issuances on projects.

AUTHORIZED BY:

LARRY D. McCALLISTER, P.E., PhD, PMP, SES Chief, Engineering and Construction Directorate of Civil Works U.S. Army Corps of Engineers

JOSEPH E. GOTT, P.E.

Chief Engineer Naval Facilities Engineering Command

EDWIN H. OSHIBA, SES, DAF

Deputy Director of Civil Engineers DCS/Logistics, Engineering & Force Protection

MICHAEL McANDREW Deputy Assistant Secretary of Defense (Facility Investment & Management) Office of the Assistant Secretary of Defense (Energy, Installations, and Environment) http://www.wbdg.org/pdfs/ufc_implementation.pdf http://www.wbdg.org/ccb/browse_cat.php?o=29&c=4 http://dod.wbdg.org/

REVISION SUMMARY SHEET

Document: UFC 3-410-02 Direct Digital Control for HVAC and Building Control Systems, formerly LonWorks® Direct Digital Control for HVAC and Other Local Building Systems

Superseding: None

Description: Design guidance and requirements for Open Direct Digital Control Systems. The guidance is particularly detailed due to the complex and definitive requirements required for the design of a digital control system and for the procurement of an Open system that supports integration into a multi-vendor system.

Reasons for Document: Initial version of this UFC covered LNS-Based LonWorks only. Extensive revisions were required to accommodate BACnet and the Niagara Framework.

Impact: There are negligible cost impacts; however, these benefits should be realized:

• The ability to procure systems competitively that can be integrated into a single supervisory system rather than requiring the procurement of several supervisory systems.

• Competitive procurement of control systems will result in cost savings. . Describe the impact. This should describe impact on design cost, initial cost, energy savings, or life cycle costs.

Unification Issues: None v

TABLE OF CONTENTS

CHAPTER 1 INTRODUCTION

1-1 BACKGROUND

1-1.1 Open system benefits and capabilities

1-1.2 References to UFGS 23 09 23.XX

1-2 OPEN SYSTEM TECHNOLOGIES

1-2.2 Control system types

1-2.3 Open system design complexity

1-3 PURPOSE AND SCOPE

1-3.1 Purpose

1-3.2 Scope

1-4 APPLICABILITY

1-5 GENERAL BUILDING REQUIREMENTS

1-6 REFERENCES

1-7 GLOSSARY

CHAPTER 2 TECHNICAL REQUIREMENTS

2-1 USE OF UFGS 23 09 XX SERIES OF SPECIFICATIONS

2-2 USE OF UFGS 23 09 23.XX

2-3 TAILORING AND DESIGNER OPTIONS IN UFGS 23 09 23.XX

2-4 \1\ USE OF PROPRIETARY NETWORKS. /1/

2-4.1 \1\ Proprietary Networks for Simple Split Systems. /1/

2-4.2 \1\ Proprietary Networks for Multi-Split Systems (Including Variable Refrigerant Flow (VRF) Systems). /1/

2-4.3 \1\ Proprietary Networks for Chiller and Boiler Plants. /1/

2-4.4 \1\ All Other Systems. /1/

CHAPTER 3 DESIGN

3-1 INTRODUCTION

3-2 BASEWIDE UMCS ARCHITECTURE

3-3 LONWORKS BCN ARCHITECTURE

3-3.1 General

3-3.2 CEA 709 Media selection

3-4 BACNET BCN ARCHITECTURE

vi

3-4.1 Device and network addressing

3-4.2 Media selection

3-5 NIAGARA FRAMEWORK NETWORK

3-5.1 Niagara Framework and LonWorks

3-5.2 Niagara Framework and BACnet

3-6 CONNECTION TO A UMCS

3-7 NETWORK HARDWARE

3-8 NETWORK DESIGN AND LAYOUT

3-8.1 Data transmission methods

3-8.2 Data integrity

3-8.3 Number of controllers per system or sequence

3-9 CYBERSECURITY

CHAPTER 4 DIRECT DIGITAL CONTROL HARDWARE AND CONTROL DEVICES 21

4-1 INTRODUCTION

4-2 LONWORKS REQUIREMENTS

4-2.1 General

4-2.2 Application specific controller

4-2.3 Application generic controller

4-2.4 General purpose programmable controller

4-3 BACNET REQUIREMENTS

4-3.1 General

4-3.2 Scheduling

4-3.3 Alarm generation

4-3.4 Trending

4-3.5 Engineering units

4-4 NIAGARA FRAMEWORK REQUIREMENTS

4-4.1 General

4-4.2 Niagara Framework and LonWorks (UFGS 23 09.01)

4-4.3 Niagara Framework and BACnet (UFGS 23 09.02)

4-5 OTHER ISSUES

4-5.1 Expansion modules and tethered hardware

4-5.2 Building management interface vii

4-5.3 Local Display Panel

4-5.4 Networked sensors and actuators

4-5.5 Hand-Off-Auto (H-O-A) Switches

CHAPTER 5 CONTROL SYSTEM DRAWINGS

5-1 CONTROL SYSTEM DRAWINGS OVERVIEW

5-2 SAMPLE DRAWINGS

5-2.1 Brackets in sample drawings

5-3 UNIQUE IDENTIFIERS

5-4 POINTS SCHEDULE

5-4.1 Overview

5-4.2 Responsibilities

5-4.3 UMCS content shown on UFGS 25 10 10 points schedules

5-4.4 Points Schedule Description and Instructions

5-5 CONTROL SYSTEM SCHEMATIC

5-5.1 Loops and devices

5-5.2 Sequencing diagrams

5-5.3 Designer notes

5-6 LADDER DIAGRAM

5-7 CONTROL LOGIC DIAGRAM

5-8 SEQUENCE OF OPERATION

5-9 THERMOSTAT AND OCCUPANCY SENSOR SCHEDULE

5-9.1 Thermostats

5-9.2 Occupancy sensors

5-9.3 Schedule entries

5-10 OCCUPANCY SCHEDULE

5-10.1 System default schedule

5-10.2 Supervisory monitoring and control schedule

5-10.3 Number of occupancy sensors to put AHU in occupied mode

CHAPTER 6 BUILDING CONTROL SYSTEM DESIGN AND IMPLEMENTATION

6-1 INTRODUCTION

6-2 PLANNING

6-3 CHOICE OF SPECIFICATION AND PROTOCOL

viii

6-4 INTEGRATION TO UMCS

6-5 PROCUREMENT CONSIDERATIONS

6-6 DDC DESIGN

6-6.1 General

6-7 DRAWING PACKAGE

APPENDIX A REFERENCES

APPENDIX B BEST PRACTICES

APPENDIX C GLOSSARY

C-1 ACRONYMS

C-2 DEFINITION OF TERMS

C-2.1 Field Control System (FCS) and Field Control Network (FCN)

C-2.2 Field Point of Connection (FPOC)

C-2.3 Industrial Control System (ICS)

C-2.4 Utility Monitoring and Control System (UMCS)

C-2.5 Utility Monitoring and Control System (UMCS) Front End

C-2.6 Utility Monitoring and Control System (UMCS) IP Network

C-3 TERMS SPECIFICALLY NOT USED BY THIS UFC

C-4 OTHER TERMINOLOGY

APPENDIX D POINTS SCHEDULE IINSTRUCTIONS

D-1 USE OF BRACKETS IN THE POINTS SCHEDULE

D-2 POINTS SCHEDULE DESCRIPTION AND INSTRUCTIONS

D-2.1 General Columns

D-2.2 Protocol-Specific Columns

D-2.3 Configuration Information

D-2.4 Point Schedule Application Notes

APPENDIX E POINT NAMING CONVENTION

E-1 POINT SCHEDULE APPLICATION NOTES

E-2 DEVICE DESCRIPTORS

E-3 TYPICAL VARIABLES OR CONTROLLED DEVICES

E-4 TYPICAL MODIFIERS

E-5 EXAMPLE POINT NAMES

E-6 OTHER ABBREVIATIONS

ix

APPENDIX F Control Logic Diagram (CLD) Overview

F-1 INTRODUCTION

F-2 FUNCTIONAL BLOCKS USED IN CONTROL LOGIC DIAGRAMS

F-2.1 Signal

F-2.2 Actuator Output

F-2.3 Sensor Input

F-2.4 Hand-Off-Auto (H-O-A) Switch

F-2.5 Constant Value

F-2.6 Signal I/O

F-2.7 Logical AND

F-2.8 Logical NOT

F-2.9 Logical OR

F-2.10 On Delay Timer

F-2.11 Switch

F-2.12 Comparator with Deadband

F-2.13 Reset Schedule

F-2.14 Math Function

F-2.15 PID Loop with Enable

F-2.16 IF Block

F-2.17 Set/Reset Latch

FIGURES

Figure 3-1 UMCS Architecture

Figure 3-2 LonWorks Building Network Architecture

Figure 3-3 BACnet Building Network Architecture

Figure 5-1 Sample Ladder Diagram

Figure 5-2 Thermostat and Occupancy Sensor Schedule

TABLES

x

This Page Intentionally Left Blank

CHAPTER 1 INTRODUCTION

1-1 BACKGROUND.

Designers, installers, and operations and maintenance (O&M) staff have struggled with the complexities and incompatibilities of multi-vendor building automation direct digital control (DDC) systems almost since they were introduced in the 1980’s. DDC systems are routinely designed and procured on a building-by-building or sub-system by sub-system basis, most notably for heating, ventilating, and air-conditioning (HVAC) systems. In the absence of specifications and criteria for Open systems, Government procurement rules which require competitive bidding make it extremely difficult if not impossible to procure new DDC systems that are compatible with existing ones and that are also compatible with a basewide or campus-wide supervisory system.

In the absence of sole-source procurement, new but incompatible DDC systems result at best in inefficiencies and at worst in complex and non-functioning systems. This is a problem with system-to-system data sharing and is a problem where multiple individual systems need to communicate with a supervisory monitoring and control (front-end) system such as a Utility Monitoring and Control System (UMCS) specified by UFGS 25 10 10. This inability to interoperate is a result of Closed systems due to vendor-specific proprietary elements. In contrast, Open DDC systems are now available. An Open DDC system is characterized by the ability for any qualified entity to readily modify, operate, upgrade, and perform retrofits on the DDC system. An Open system:

• Permits multiple devices from multiple vendors to readily exchange information.

• Provides the capability to easily replace any device with another device procured from multiple sources.

• May have proprietary components within devices, but these proprietary components must be a small percentage of the overall device.

• May have fees associated with use of certain components.

In short, an Open system is one (integrated, multi-vendor) system where there is no future dependence on any one Contractor or controls vendor.

1-1.1 Open system benefits and capabilities.

Open communications and data sharing between multi-vendor systems and with a third party supervisory system is necessary to achieve effective system operation. Some of the benefits and capabilities of Open multi-vendor DDC systems include:

• Competitive procurement, most notably at the building and sub-system level.

• An operator workstation/user interface that provides for the same look and feel for monitoring and control regardless of which vendor’s DDC system or sub-system an operator is viewing. As a result, system operators need only become proficient with one user interface.

• An operator workstation/user interface (software) that provides for management of base-wide system operations such as: remote alarm reporting, remote scheduling (on/off control), remote set point override, data logging and reports, energy management including load shedding, utilities monitoring/measurement for the purpose of monitoring energy performance contracts, and initial diagnosis of service calls. The ability to monitor multiple vendor’s systems from a single Operator Workstation/User Interface (OWS/UI) with the same look and feel across all vendor’s systems. As a result, through a single user interface, system operators and managers are afforded the means to efficiently and effectively manage base-wide operations.

• A whole-building approach to systems integration. This includes the efficient inter-connection of HVAC control sub-systems. For example, terminal unit equipment, such as VAV boxes can be readily interfaced to the servicing air handler to provide a call for cooling. In addition, the whole-building approach provides the capability for integrating non-HVAC sub-systems such as fire and security

• (For a LonWorks system) groundwork for establishment of a non-proprietary and openly accessible ‘point-database’ in support of communications-network management requirements.

1-1.2 References to UFGS 23 09 23.XX.

This UFC is intended to be used with UFGS 23 09 00 (Instrumentation and Control for HVAC), UFGS 23 09 23.01 (LonWorks® Direct Digital Control for HVAC and Other Building Systems), and UFGS 23 09 23.02 (BACnet Direct Digital Control for HVAC and Other Building Systems). This document will often use “UFGS 23 09 23.XX” when the intent is to refer to both the LonWorks and BACnet UFGS.

1-2 OPEN SYSTEM TECHNOLOGIES.

The Open systems approach described in this UFC is based on several possible technologies: BACnet, LONWORKS, or Niagara Framework.

1-2.1.1 BACnet.

The term “BACnet” is used in this UFC as the shorthand reference to the ANSI/ASHRAE Standard 135, specifically referring to the communications protocol specified there-in. The term “BACnet” is also used in this UFC to loosely describe a collection of technologies, including hardware, and software, vendors and installers relating to or based on the ASHRAE Standard 135 communications protocol. While every attempt has been made to distinguish which meaning is intended, in some cases the reader must make the determination from context

1-2.1.2 LONWORKS®

ANSI/CEA standard 709.1-C communications protocol (sometimes referred to as LonTalk®) and on LONWORKS® Network Services (LNS®) network operating system.

The standard protocol supports Open communications while LNS supports Open network management. 'CEA 709.1' is used in this UFC as the shorthand reference to the ANSI/CEA standard 709.1-C communications protocol. In this UFC the term LONWORKS® is used to loosely describe a collection of technologies (including hardware, and software), vendors and installers relating to or based on the CEA 709.1 communications protocol

1-2.1.3 Niagara Framework.

The Niagara Framework is a protocol and set of technologies developed and owned by Tridium Inc. which is licensed to multiple vendors. Different vendors provide this system under different product names, but the overall term used by Tridium is “Niagara”. The Niagara Framework may be used in conjunction with either the BACnet or LonWorks option to design a system using BACnet or LonWorks that also can interoperate with a Niagara Framework front end installed in accordance with UFGS 25 10 10 and/or \2\ UFC 3-470-01, Utility Monitoring And Control System (UMCS) Front End and Integration /2/. Note that use of Niagara Framework will override/trump some design options that would normally be used in a BACnet or LonWorks system.

1-2.2 Control system types

The combination of technologies result in 4 possible building control system types:

• A BACnet building using the BACnet standard

• A BACnet building using both the BACnet standard and the Niagara Framework

• A LonWorks building using CEA 709.1 and LNS

• A LonWorks building using both CEA 709.1 and the Niagara Framework

1-2.3 Open system design complexity

The design of an Open system is not simple. It requires attention to a great deal of detail. This UFC, the specifications, and accompanying drawings were developed to minimize the time and effort required on the part of the designer.

The level of detail contained in the guide specification and this UFC is necessary because of the variety of approaches that can be used to implement BACnet, or CEA 709.1-C, or Niagara Framework where, in the absence of this detail, would very likely result in incompatible systems.

1-3 PURPOSE AND SCOPE.

1-3.1 Purpose

The design concept described in this UFC provides definitive guidance intended to streamline DDC system design and installation leading to maintainable, interoperable, extensible, and non-proprietary control systems. This UFC also contains minimal project requirements. The purpose of this UFC is two-fold, to provide for commonality and compatibility of control systems:

• Commonality. Describes a definitive methodology for the design of building-level control systems and strategies (primarily for HVAC) where the intent is to achieve at least a degree of commonality in systems designed and procured through different channels. Common sequences of operation are specified in UFGS 23 09 93.

• Compatibility. Describes a definitive methodology to obtain multi-vendor systems that can communicate and interoperate with each other and with a supervisory monitoring and control system such as a basewide UMCS through the use of an Open communications protocol.

1-3.2 Scope.

This UFC describes the design of HVAC control systems and the associated building control network that can interface to a UMCS in an Open and non-proprietary manner.

1-3.2.1 HVAC control sequences and instrumentation.

These topics are covered in UFGS 23 09 13, UFGS 23 09 93.

1-3.2.2 Building controllers and control network.

This UFC describes designer selections for DDC hardware and software as well as the Building Control Network (BCN) communications including data exchange, architecture, and cabling.

1-3.2.3 UMCS interface.

The DDC system can function as a stand-alone system with reduced functionality (limited user interface, no trending etc.) but is intended to be integrated into a UMCS in accordance with the UMCS guidance (UFC 3-401-01 and UFGS 25 10 10) to provide for remote supervisory monitoring and control of the DDC system. This UFC (3-410-02) and UFGS 23 09 23.XX helps to ensure that the building-level control system is capable of being interconnected with a UMCS installed in accordance with UFGS 25 10 10 and/or \2\ UFC 3-470-01, Utility Monitoring And Control System (UMCS) Front End and Integration /2/. Even in the absence of a UMCS, this UFC describes the methodology for designer selection and specification of data exchange parameters including requirements that will facilitate subsequent non-proprietary UMCS interface.

1-3.2.4 Other systems.

Although not directly addressed or specified in the UFC or UFGS the methodology, approach, and many of the requirements defined in this UFC and UFGS 23 09 23.XX can be used in the design of other (non-HVAC) Open DDC systems such as water and sanitary sewer systems, electrical systems, lighting, and other utility systems and equipment.

1-4 APPLICABILITY.

This UFC is applicable to all HVAC control system design, both for new construction and renovation. This UFC and the guide specifications may also be applied to other non-HVAC building control when those systems use LonWorks or BACnet.

1-5 GENERAL BUILDING REQUIREMENTS.

Comply with UFC 1-200-01, DoD Building Code (General Building Requirements). UFC 1-200-01 provides applicability of model building codes and government unique criteria for typical design disciplines and building systems, as well as for accessibility, antiterrorism, security, high performance and sustainability requirements, and safety.

Use this UFC in addition to UFC 1-200-01 and the UFCs and government criteria referenced therein.

1-6 REFERENCES.

Appendix A contains a list of references used in this document. The publication date of the code or standard is not included in this document. Unless otherwise specified, the most recent edition of the referenced publication applies.

1-7 GLOSSARY.

Appendix C contains acronyms, abbreviations, and terms. In addition, UFGS 23 09 00 contains an extensive list of definitions.

CHAPTER 2 TECHNICAL REQUIREMENTS

2-1 USE OF UFGS 23 09 XX SERIES OF SPECIFICATIONS.

Unless specifically indicated in this UFC or with specific written permission from the authority having jurisdiction, the design of a building control system must use UFGS 23 09 00 and either UFGS 23 09 23.01 or UFGS 23 09 23.02 (as appropriate) without edits beyond the use of tailoring options and designer option.

2-2 USE OF UFGS 23 09 23.XX.

The implementation of a building control system requires highly specific and prescriptive specifications. UFGS 23 09 23.01 (for LonWorks based BCS) and UFGS 23 09 23.02 (for BACnet based BCS) incorporates these requirements, and makes use of SpecsIntact Tailoring Options and designer options (bracketed text with notes) to allow for project-specific editing.

Unless specifically indicated in this UFC or with specific written permission from the authority having jurisdiction, the design of a building control system must use either UFGS 23 09 23.01 or UFGS 23 09 23.02 (as appropriate) without edits beyond the use of tailoring options and designer options.

2-3 TAILORING AND DESIGNER OPTIONS IN UFGS 23 09 23.XX.

The use of tailoring options and designer options in either UFGS 23 09 23.01 or UFGS 23 09 23.02 must be in accordance with this UFC.

2-4 \1\ USE OF PROPRIETARY NETWORKS. /1/

\1\ The use of multiple devices communicating on a proprietary networks is allowed as an exception to the open protocol requirements of UFGS 23 09 23.01 or UFGS 23 09

23.02 only when the specific requirements in the following paragraphs are met. Note that internal communications within a single piece of packaged equipment (package unit) need not meet the open protocol requirements, but the packaged equipment must be provided with an interface meeting the open protocol requirements.

When including proprietary networks in a design as permitted in this UFC, the systems specifically permitted to use proprietary networks must be indicated in UFGS 23 09 00.

/1/

2-4.1 \1\ Proprietary Networks for Simple Split Systems. /1/

\1\ A simple split (DX) system consisting of a single indoor unit and a single outdoor unit from the same manufacturer is always permitted to use a proprietary network between the two units provided that one unit has an open protocol interface meeting the requirements of the UFGS. Include a Points Schedule in the design package for the split system at the system interface. /1/

2-4.2 \1\ Proprietary Networks for Multi-Split Systems (Including Variable Refrigerant Flow (VRF) Systems). /1/

\1\ Multi-split (including variable refrigerant flow (VRF)) systems using proprietary networks connecting multiple units which operate together must meet the following requirements:

• A gateway must be provided between the proprietary network and the open protocol control system required by UFGS 23 09 23.01 or UFGS 23 09 23.02 to provide a functional interface between the two networks. The open protocol side of the gateway must meet the requirements of UFGS 23 09 23.01 or UFGS 23 09 23.02.

• A Point Schedule for the system must be included in the design package to define the functional interface of the system to the open protocol control system.

• All units must be products of a single manufacturer.

• The units must operate using a common sequence of operation which operates the units in a manner that requires operational parameters be shared between them. The units must use a factory provided program for the sequence of operation; this program may be field configurable but units must not be field programmed.

• The solution using the proprietary network must have a lower life-cycle cost than at least two (2) alternate solutions not using proprietary networks.

• The System Owner receiving the control system must approve of and accept the use of the system. When a System Owner does not accept a system using a proprietary network it must not be used regardless of other factors.

• For USACE projects, the Utility Monitoring and Control System Mandatory Center of Expertise (UMCS MCX) must review the design, life cycle cost analysis, and System Owner approval and concur prior to specifying a system using a proprietary network.

When allowing proprietary networks for multi-split systems, the life cycle cost analysis, System Owner approval, and UMCS-MCX concurrence (for USACE projects) must be included in the design documents. The systems specifically permitted to use proprietary networks must be indicated in the table provided in UFGS 23 09 00. /1/

2-4.3 \1\ Proprietary Networks for Chiller and Boiler Plants. /1/

\1\ Boilers or chillers using proprietary networks connecting multiple units which operate together must meet the following requirements:

• A gateway must be provided between the proprietary network and the open protocol control system required by UFGS 23 09 23.01 or UFGS 23 09 23.02 to provide a functional interface between the two networks. The open protocol side of the gateway must meet the requirements of UFGS 23 09 23.01 or UFGS 23 09 23.02.

• A Point Schedule for the system must be included in the design package to define the functional interface of the system to the open protocol control system.

• All units must be from the same manufacturer.

• All units must be co-located in the same room, and the network connecting them must be fully contained in that room.

• The units must operate using a common "plant" sequence of operation which stages the units in a manner that requires operational parameters be shared between them and which cannot be accomplished with a single lead-lag command from a third-party controller.

• The design must include specific model chiller and boilers. If the design is not specifying the exact equipment, do not include the exception as part of the design; UFGS 23 09 00 includes a mechanism by which the installing contractor can request the exception if needed. (In most cases, this means that this exception will apply primarily to design-build projects and not design-bid-build.)

When allowing proprietary networks for chiller or boiler plants, the design documents must include a statement that the system meets the necessary requirements for use of a proprietary networks and the systems specifically permitted to use proprietary networks must be included in the table provided in UFGS 23 09 00. /1/

2-4.4 \1\ All Other Systems. /1/

\1\ The specific exceptions defined in this UFC were determined as warranted based on implementation and maintenance considerations, and on industry capabilities to provide solutions meeting open systems requirements and apply only to the indicated systems.

For all other systems, the use of multiple devices communicating on a proprietary networks requires a waiver from UFC requirements.

To suggest additional systems for consideration for establishing exception procedures, submit a Criteria Change Request (CCR) to this UFC. /1/

CHAPTER 3 DESIGN

3-1 INTRODUCTION.

This chapter describes building-level Open-communications control system architecture, device functionality, and control devices for HVAC and other building-level monitoring and control applications. The communications network and devices are based on one of:

• LonWorks® technology and CEA 709.1 communications protocol with LNS

• LonWorks and the Niagara Framework

• BACnet, ASHRAE-135

• BACnet and the Niagara Framework

This UFC will primarily focus on either the LonWorks or BACnet option, with supplemental material provided to cover the Niagara Framework variant. Design of an Open-communications building-level control system does not require an extensive familiarity with CEA 709.1 protocol, BACnet, or the Niagara Framework, but it is critical that the designer understand that these protocols can be implemented in a manner that is not Open and thus can lead to incompatible systems. Therefore, this chapter contains supplemental information to be used in conjunction with UFGS 23 09 23.XX.

3-2 BASEWIDE UMCS ARCHITECTURE.

As illustrated Figure 3-1, a basewide system consists of a UMCS (specified by UFGS 25 10 10) containing to one or more building-level DDC systems (specified by UFGS 23 09 00 and UFGS 23 09 23.XX). The network architecture consists of a basewide IP network and one or more building-level networks. DDC UFGS 23 09 23.XX refers to the building-level network as the Building Control Network (BCN). A field point of connection (FPOC) provides an interface between the basewide IP and BCN networks. Since the FPOC is the location where the contractor-installed Building Control Network (BCN) meets the basewide IP network, the location of the FPOC must be coordinated with the base IT/networking staff.

Figure 3-1 UMCS Architecture

3-3 LONWORKS BCN ARCHITECTURE.

3-3.1 General.

As illustrated in Figure 3-2, a LonWorks (with or without Niagara Framework) BCN consists of an IP network with one or more (in the case of LonWorks with LNS) CEA 852 routers or (in the case of LonWorks with Niagara) Niagara Framework Supervisory Gateways. Beneath each CEA 852 router or Niagara Framework Supervisory Gateway is either TP/XF-1250 media or TP/FT-10 media (not all Niagara Framework Supervisory Gateways will necessarily have a network beneath them). TP/XF-1250 media functions as a non-IP network backbone and will only have Lon-to-Lon routers connected to it.

Each Lon-to-Lon router will, in turn, have TP/FT-10 media connected, with individual DDC Hardware connected to the individual TP/FT-10 networks.

TP/FT-10 media directly connected to a CEA 852 router or Niagara Framework Supervisory Gateway may have DDC Hardware connected to it, or it may be used as a non-IP network backbone (identical to the use of TP/XF-1250 media). When used as a non-IP network backbone it will only have Lon-to-Lon routers connected to it (with TP/FT-10 networks and DDC Hardware connected to the individual Lon-to-Lon routers).

The LNS-based LonWorks architecture produces a logically flat network in the building where each node can communicate directly with any other node without the intervention of another controller.

Figure 3-2 LonWorks Building Network Architecture

3-3.2 CEA 709 Media selection.

UFGS 23 09 23.01 specifies the use of one of: IP, TP/XF-1250, or TP/FT-10 media;

each has advantages and disadvantages:

• IP is necessary because the UMCS uses IP, so at some point the network needs to connect to IP. For a smaller building, this may as simple as a single IP port on a CEA 852 router or Niagara Framework Supervisory Gateway. Larger buildings will likely have multiple devices on IP and a contractor-installed IP network. IP also has by far the greatest bandwidth of the media types. IP does have the downside of having the most IA (Information Assurance) issues. Future management of the IP network will vary from service to service and possibly even from site to site, but all IP networks will be required to meet some level of Information Assurance (IA) requirements.

• TP/XF-1250 communicates at 1250 kbps, which is considerably faster than TP/FT-10, but not as fast as IP. TP/XF-1250 is not part of the CEA 709 standard, but it is a de-facto standard for a high-speed Lon media. There are very few DDC Hardware devices using TP/XF-1250, so its use is limited to that of a backbone media. TP/XF-1250 must be installed in a doubly-terminated bus configuration.

• TP/FT-10 communicates at 78 kbps, which is the slowest of the 3 but still sufficiently fast to allow its use as the main media type in fairly large installations.

It is covered by CEA 709 and is universally supported; almost all devices support TP/FT-10 and in these specifications it is the only media that can be connected to DDC Hardware (other than Niagara Framework Supervisory Gateways).

TP/FT-10 must be installed in a doubly-terminated bus configuration

Use of other media types may limit future competition by giving an advantage to the limited number of vendors whose products support the non-standard media. Therefore use of alternative media is prohibited by the guide specifications. There may be some situations where a different CEA 709 media is needed – such the use of Power Line for retrofits where it is impossible to run new media or fiber optic for inter-building runs where electrical isolation is required. Do not specify or permit alternate media without written authorization from the AHJ.

3-4 BACNET BCN ARCHITECTURE.

BACnet uses the term internetwork to refer to the entire connected BACnet system, consisting of one or more interconnected individual BACnet networks. A particular site may have multiple disconnected internetworks; each would be a separate BACnet system.

As illustrated in Figure 3-3, a BACnet (with or without Niagara Framework) BCN consists of an IP network with a mixture of DDC Hardware (including, in the case of the Niagara Framework, Niagara Framework Supervisory Gateways) and BACnet MS/TP – to- BACnet IP routers (which may be furnished as part of DDC Hardware). Each MS/TP –to- IP router or Niagara Framework Supervisory Gateway may have MS/TP networks beneath it, with DDC Hardware on the individual MS/TP networks. Each project will have a single Field Point of Connection (FPOC) which provides an interface between the basewide IP network and the BCN network installed by that project.

Figure 3-3 BACnet Building Network Architecture

3-4.1 Device and network addressing.

BACnet addressing uses two pieces of data which must be unique throughout the Internetwork - Device IDs and Network Numbers. Unlike Lon-based systems installed under UFGS 23 09 23.01, BACnet does not provide a mechanism to globally manage this data across multiple vendors and the installation must manually manage these numbers:

• Network Number. The network number is assigned to every BACnet network and must be unique across the entire BACnet internetwork. The network number is between 1 and 65,535.

o The basewide BACnet internetwork should have a single BACnet/IP network; all BACnet devices residing on the IP network should have the same BACnet network number. While this network may well span multiple IP subnets, from the perspective of BACnet, it will logically consist of a single BACnet/IP network and only use a single Network Number. This network must be assigned Network Number=1.

o Each MS/TP network (of which large projects will have several) also needs a site-wide number. Since network numbers can range from 1 – 65,535, and most sites have at most a few thousand buildings, one option is to assign a range of network numbers to each building by building number. So, for example, building 2705 might have network numbers in the range 27,050 – 27,059. Another option is to assign each vendor a range of network numbers and force the vendors to keep track (site-wide) which numbers they have used. Finally, network numbers could simply be assigned site-wide in increasing consecutive order. This requires some care when multiple independent BACnet projects are underway at the same time.

• Device Object Identifier. Every device on the internetwork must have a unique Object identifier for the Device Object, this is often referred to as the Device ID.

This number can be any value between 1 and 4,194,302. Similar to Network Numbers, Device IDs must be globally unique within a site (the BACnet internetwork). The same methods suggested for managing MS/TP network numbers can be used for managing Device IDs, with the additional complication that a single project may include devices from multiple vendors and projects using devices from multiple vendors will need multiple tools to manage Device IDs on a single project

Within a specific project, installers will have some method to maintain unique Device Object Identifiers within the device manufacturer’s product lines. This however does not guarantee unique Device Object Identifiers across manufacturers. It also does not ensure unique Device IDs and Network Numbers when a specific project is later integrated into a basewide BACnet internetwork. Coordination with the project site concerning their management procedure for these values is critical. If the project site does not have an existing procedure for managing these values coordinate with them to develop one. For the Army, assistance with the resolution of this issue can be obtained from the UMCS MCX at Huntsville Center.

3-4.2 Media selection.

UFGS 23 09 23.02 specifies the use of either MS/TP or IP.

• Master-Slave/ Token Passing (MS/TP) is a data link protocol as defined by the BACnet standard and the majority of DDC controllers used will communicate BACnet MS/TP over a doubly terminated field bus network compliant with EIA/TIA-485. In order to avoid interoperability issues, MS/TP media shall operate at 38.4 kbps, use 3 wire (twisted pair with reference) with shield media and shall be installed with 2 sets of network bias resistors and no more than 32 nodes per segment. MS/TP is by far the slowest of any media types in either UFGS 23 09

23.01 or UFGS 23 09 23.02.

• Some BACnet controllers will likely use BACnet/IP in accordance with ASHRAE- 135 (2012) Annex J. While installation of this media is the responsibility of the controls contractor, this network will, when integrated into a basewide UMCS, connect to the basewide IP network. Future management of the IP network will vary from service to service and possibly even from site to site, but all IP networks will be required to meet some level of Information Assurance (IA) requirements.

Use of other media types may limit future competition by giving an advantage to the limited number of vendors whose products support the non-standard media. Therefore use of alternative media should generally be avoided, though there may be cases (retrofits where it is impossible to run new media) where Zigbee (wireless – but carefully coordinate wireless with the site IT and RF management groups) is desired, or inter-building runs where fiber optic should be considered for its electrical isolation characteristics.

3-5 NIAGARA FRAMEWORK NETWORK.

The Niagara Framework provides an overlay system. At the bottom level of the architecture, there are non-Niagara Framework controllers based on either LonWorks or BACnet. Above those controllers are Niagara Framework Supervisory Gateways which connect the individual building to a Niagara Framework UMCS Front End. These devices function as gateways because the protocol for devices under them is either LonWorks or BACnet, while the protocol above these devices (connecting to the UMCS Front End) is the Fox protocol. In most aspects, the architecture when the Niagara Framework is selected is similar to the base (non-Niagara) architectures discussed above. Differences are discussed below.

3-5.1 Niagara Framework and LonWorks.

The Niagara Framework Supervisory Gateway will take the place of the CEA 852 router to provide a connection to the IP network. The Niagara Framework Supervisory Gateway is a gateway and does not route CEA 709.1 to the IP network. The Niagara Framework Supervisory Gateway is DDC hardware and may be connected directly to the IP network.

The Niagara Framework engineering tool will be used for network management instead of an LNS-based tool. For many requirements, an LNS-based requirement is replaced with a similar requirement based on the Niagara Framework engineering tool. The communication between the building control system and the front end will be via Fox, not CEA 709.1

3-5.2 Niagara Framework and BACnet.

The Niagara Framework Supervisory Gateway will function as the BACnet MS/TP–to-IP Router. The Niagara Framework Supervisory Gateway does route BACnet, and all MS/TP networks must be connected to a Niagara Framework Supervisory Gateway.

The communication between the building control system and the front end will be via Fox, not BACnet. Non-Niagara devices on the IP network must use the Niagara Framework Supervisory Gateway to communicate with the Niagara Framework front end.

3-6 CONNECTION TO A UMCS.

The building control system will perform all necessary control functionality in a stand-alone mode but does not provide an operator interface (other than local display panels) for monitoring and control of the network. If the building is to be operated in a stand-alone mode for an extended period and monitoring and control functionality are required, use the applicable portions of UFGS 25 10 10 to obtain a local monitoring and control system. Integration of the building control system to the UMCS is specified in UFC 3-470-01 and UFGS 25 10 10.

3-7 NETWORK HARDWARE.

In addition to media, the control network may contain the following types of hardware.

• Repeaters: A repeater is a device that connects two (or more) pieces of media, and passes all traffic between the two pieces of media. Repeaters may allow for longer cable runs in some cases, but not others. The BACnet specification does not allow the use of repeaters. The LonWorks specification allows the use of routers which are configured as repeaters (but prohibits “physical layer” repeaters).

• Media Converter: A media converter is a repeater that changes media types.

The network architecture defined in UFGS 23 09 23.XX does not use media converters, but they may be needed if non-standard media was authorized.

• Router: A router is similar to a repeater, but performs the additional function of packet filtering based on destination address. A router will only pass traffic that needs to be sent to another output port. Routers may also convert between media types. Both UFGS 23 09 23.01 and UFGS 23 09 23.02 specify the use of routers.

• Gateway: A gateway translates from one protocol to another. The use of gateways, other than Niagara Framework Supervisory Gateway in a Niagara Framework project, is severely restricted in UFGS 23 09 23.XX.

3-8 NETWORK DESIGN AND LAYOUT.

Network layout is left largely to the building-level controls Contractor as specified in

UFGS 23 09 23.XX.

While the Contractor is responsible for selecting the details of the architecture and ensuring that the proposed system does not saturate the network, UFGS 23 09 23.XX provide specific additional requirements to help ensure those limits are not exceeded:

• Use of higher speed media and use of a backbone architecture

• Group devices that need to communicate often on a common local control bus

• Limit the amount of information sent to the UMCS. A modern UMCS can easily demand data from the local controls faster than the building network can deliver the data. Coordinate with the UMCS installer to limit “always-active” data requests from the UMCS such as trending to those really required by the installation.

• Ensure the Contractor is careful in selecting data transfer rates and integrity methods. Use “Send on Change” with reasonable change values to avoid sending data more often than required. Except for critical data, do not require an acknowledgement or confirmation that data was received.

3-8.1 Data transmission methods.

There are two primary mechanisms through which data transfer data occurs; polling and send on change. These data transfer aspects of the protocol along with the quantity of data transferred govern how much bandwidth is used. Polling occurs when a receiver of data requests data from a transmitter. This is generally a periodic event with a defined period. Polling can occur at any time and a device can always poll another device for data. Send on change, often referred to as Change Of Value (COV), is another form of data transfer where a data source sends (on its own initiative) data to a recipient. In most cases, the specifications require the use of COV.

3-8.2 Data integrity.

DDC networks are not 100% reliable. While proper network design, media selection and installation can improve network reliability, some dropped data packets are inevitable. Both LonWorks and BACnet have mechanisms to ensure reliable data transmission even when the underlying network is unreliable and the specification requires these methods where appropriate.

3-8.3 Number of controllers per system or sequence.

Although sequences are generally implemented in a single controller with sufficient inputs and outputs, the specifications allow a single sequence or system to be split across multiple controllers. There are designer options in the UFGS to select a preference for one approach over the other. Discuss this with the installation to determine if they have a preference. UFGS 23 09 23.XX places the burden on the Contractor to decide when distributed control should be used.

3-9 CYBERSECURITY.

Cybersecurity is an ever-changing area, and it’s vital to coordinate IA requirements both with the site networking personnel and with the respective service or agency for each project. UFC 4-010-06, Cybersecurity of Facility-Related Control Systems provides guidance on incorporating cybersecurity into the design of control systems, and includes points of contact for each Service. For the Army, control system design, including cybersecurity, should be coordinated with the UMCS Mandatory Center of Expertise (MCX) at Huntsville.

CHAPTER 4 DIRECT DIGITAL CONTROL HARDWARE AND CONTROL DEVICES

4-1 INTRODUCTION.

This chapter describes control devices and the DDC Hardware specified in UFGS 23 09 23.XX including the extended requirements needed to implement an Open system. It also describes the related terms and concepts pertaining to LONWORKS, BACnet, and the Niagara Framework.

4-2 LONWORKS REQUIREMENTS.

4-2.1 General.

Any device, other than network hardware, that communicates over the CEA 709.1 network is considered DDC Hardware. In general, the term DDC Hardware is used interchangeably with the term controller, but there are devices such as smart sensors and actuators that communicate on the network and are considered DDC Hardware but are not traditionally called controllers even though they may in fact have control functionality (like a feedback control loop). All DDC Hardware must:

• Communicate only using CEA 709.1C using a TP/FT-10 transceiver for use on a TP/FT-10 network at 78.1 kbps.

• Use Standard Network Variable Types (SNVTs). SNVTs provide a common set of standards defining how data is sent over the network, including engineering units

• Meet the LonMark Interoperability guidelines. These guidelines provide a foundation for interoperability and devices meeting these guidelines are readily available.

• Be provided with an external interface file (XIF file). This is a text file that tells a Network Management Tool what the interface (inputs, outputs, configuration settings) of the controller is.

Some of these requirements may be difficult to confirm for some devices, specifically programmable controllers. Product data sheets can provide a good indication of whether a device, particularly an application specific controller, meets LonMark Guidelines. In addition, LonMark International has a self-certification checklist that vendors can use to certify that a device meets the LonMark Guidelines.

Where Lonworks falls short is in defining a standard interface between the BCS and the UMCS front end. In particular, there is no well-supported standard for either alarming or trending; therefore these functions are not specified in UFGS 23 09 23.01 (they are specified in UFGS 25 10 10 if the LonWorks tailoring option is selected). DDC Hardware is further broken down into three categories, Application Specific Controllers, Application Generic Controllers, and General Purpose Programmable Controllers, each of which has additional requirements it must meet.

4-2.2 Application specific controller.

An application specific controller (ASC) is supplied with a factory-installed (and fixed) application program. Example ASCs include VAV box controllers, fan coil unit controllers, ‘smart’ actuators and ‘smart’ sensors. An ASC is configured for the specific application in which it is used. UFGS 23 09 23.01 requires, with rare exceptions, that ASCs be LonMark Certified to meet a specific Functional Profile. Functional Profiles describe standard node communications and consists of mandatory and optional input and output SNVTs, mandatory and optional configuration properties, and finally a manufacturer specific section. UFGS 23 09 23.01 also requires, with rare exceptions that ASCs be provided with an LNS® Plug-in to provide a semi-standard GUI for device configuration

4-2.3 Application generic controller.

An application generic controller (AGC) is similar to an ASC, but has a limited programming capability. Programming these controllers does not change the controller ProgramID, so these controllers can be (and often are) programmed through an LNS plug-in. UFGS 23 09 23.01 has specific requirements for AGCs which includes a mix of ASC and GPPC requirements. These controllers are capable of executing most of the sequences specified in UFGS 23 09 93. Further, since they can be re-programmed remotely and without changing the ProgramID, they are often preferred to GPPCs.

4-2.4 General purpose programmable controller.

A general purpose programmable controller (GPPC) comes from the factory without a fixed application program and must be programmed for the application in which it is used. This makes the GPPC more flexible and powerful than an ASC, but more complicated and costly as well. UFGS 23 09 23.01 requires the GPPC to conform to the LonMark Interoperability Guide.