UFC-3-410-02_DDC.pdf

UFC 3-410-02

19 Nov 2008

UNIFIED FACILITIES CRITERIA (UFC)

LONWORKS® DIRECT DIGITAL

CONTROL FOR HVAC AND OTHER

LOCAL BUILDING SYSTEMS

APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED

UNIFIED FACILITIES CRITERIA (UFC)

LONWORKS® DIRECT DIGITAL CONTROLS FOR HVAC AND OTHER LOCAL

BUILDING 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.

U.S. ARMY CORPS OF ENGINEERS (Preparing Activity)

NAVAL FACILITIES ENGINEERING COMMAND

AIR FORCE CIVIL ENGINEER SUPPORT AGENCY

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

Change No. Date Location

This UFC supersedes: UFC 3-410-02A

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 more 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 Support Agency (AFCESA) 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 (CCR). 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/.

Hard copies of UFC printed from electronic media should be checked against the current electronic version prior to use to ensure that they are current.

AUTHORIZED BY:

JAMES C. DALTON, P.E.

Chief, Engineering and Construction U.S. Army Corps of Engineers

JOSEPH E. GOTT, P.E.

Chief Engineer Naval Facilities Engineering Command

PAUL A. PARKER

The Deputy Civil Engineer DCS/Installations & Logistics Department of the Air Force

Dr. GET W. MOY, P.E.

Director, Installations Requirements and Management Office of the Deputy Under Secretary of Defense (Installations and Environment) i

CONTENTS

CONTENTS ..................................................................................................................... i FIGURES ........................................................................................................................iv TABLES .......................................................................................................................... v

CHAPTER 1 INTRODUCTION

1-1 BACKGROUND

1-2 PURPOSE

1-3 SCOPE

1-3.1 HVAC control 1-3.2 Building control network 1-3.3 UMCS interface 1-3.4 Other systems

1-4 APPLICABILITY

1-5 REFERENCES

CHAPTER 2 CONTROL SYSTEM NETWORK

2-1 INTRODUCTION

2-2 ARCHITECTURE

2-3 BUILDING CONTROL NETWORK

2-3.1 General 2-3.2 TP/FT-10 media 2-3.3 Other media types 2-3.4 Media selection 2-3.5 Building control network - backbone 2-3.6 Building control network - local control bus

2-4 CONNECTION TO A UMCS

2-5 NETWORK DESIGN AND LAYOUT

2-6 NETWORK HARDWARE

2-6.1 Repeater 2-6.2 Media converter 2-6.3 Router 2-6.4 Network bandwidth 2-6.5 Other architecture issues

2-7 ADDRESSING, DATA TRANSMISSION, AND DATA INTEGRITY

2-7.1 Addressing 2-7.2 Data transmission 2-7.3 Data integrity

CHAPTER 3 DIRECT DIGITAL CONTROL HARDWARE AND CONTROL DEVICES. 17

3-1 INTRODUCTION

3-1.1 SNVTs 3-1.2 Functional profile

3-2 DDC HARDWARE

3-2.1 Application specific controller 3-2.2 Application generic controller 3-2.3 General purpose programmable controller 3-2.4 Local display panel ii

3-2.5 CEA-709.1 sensors and actuators 3-2.6 Building management interface

3-3 FIELD DEVICES

3-3.1 Sensors (input devices) 3-3.2 Actuators (output devices) 3-3.3 Multi-function devices

CHAPTER 4 TYPICAL CONTROL LOOPS

4-1 INTRODUCTION

4-2 BASIC CONTROL LOOP

4-2.1 Control action and device failsafe

4-3 CONTROL LOGIC DIAGRAMS

4-3.1 Control logic diagram basic sequence 4-3.2 System enabling logic 4-3.3 Alarms and shutdown CLD

4-4 CONTROL LOOPS

4-4.1 Preheat coil control loop 4-4.2 Cooling coil control loop 4-4.3 Heating coil control loop with setpoint reset 4-4.4 Mixed air temperature control with economizer 4-4.5 Outside air flow control 4-4.6 Variable air volume control loops 4-4.7 Variable speed pump control 4-4.8 Humidity control loop 4-4.9 Alarms

CHAPTER 5 CONTROL SYSTEM DRAWINGS

5-1 CONTROL SYSTEM DRAWINGS OVERVIEW

5-2 CONTRACT DRAWING SET

5-3 SYMBOLS AND 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-4.5 Points schedule application notes

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 iii

5-10.2 Supervisory monitoring and control schedule 5-10.3 Number of occupancy sensors to put AHU in occupied mode

CHAPTER 6 PROJECT IMPLEMENTATION

6-1 INTRODUCTION

6-2 PLANNING

PROCUREMENT CONSIDERATIONS

6-2.1 Non-proprietary procurement 6-2.2 Proprietary procurement

6-3 DDC DESIGN

6-3.1 General

6-4 SCOPE OF THE DESIGN

6-5 CONTRACTING MECHANISMS

6-6 COORDINATION

6-6.1 IT (DOIM) Coordination 6-6.2 Mechanical design coordination 6-6.3 Electrical design coordination 6-6.4 Project site coordination

6-7 EDITING THE SPECIFICATION

6-7.1 UFGS 23 09 23 edits 6-7.2 Other specification editing/coordination

6-8 DRAWING PACKAGE

6-9 Other

APPENDIX A GLOSSARY

APPENDIX B CONTROL LOGIC DIAGRAM (CLD) TUTORIAL

B-1 Introduction B-2 Functional blocks used in control logic diagrams

B-2.1 Signal B-2.2 Actuator Output B-2.3 Sensor Input B-2.4 Hand-Off-Auto (H-O-A) Switch B-2.5 Constant Value B-2.6 Signal I/O B-2.7 Logical AND B-2.8 Logical NOT B-2.9 Logical OR B-2.10 On Delay Timer B-2.11 Switch B-2.12 Comparator with Deadband B-2.13 Reset Schedule B-2.14 Math Function B-2.15 PID Loop with Enable iv

FIGURES

Figure 2-1. UMCS and DDC System Architecture Figure 4-1. Basic Control Loop Figure 4-2. Direct Control Action Figure 4-3. Reverse Control Action Figure 4-4. Basic Sequence for a Cooling Coil Control Loop Figure 4-5. System Enabling Logic Figure 4-6. Alarms and Shutdown CLD Figure 4-7. Preheat Coil Control Schematic Figure 4-8. Preheat Coil CLD Figure 4-9. Cooling Coil Control Schematic Figure 4-10. Cooling Coil CLD Figure 4-11. Typical Setpoint Reset Schedule for Heating Coil Air Temperature Figure 4-12. Heating Coil with Outside Air Reset Control Schematic Figure 4-13. Economizer/Mixed Air Temperature Control Schematic Figure 4-14. OA-Only Dry Bulb Economizer CLD Figure 4-15. OA-Only Economizer Setpoint Selection Example for Greenville, NC Figure 4-16. Greenville SC Weather Data for OA-Only Economizer Setpoint Selection Example Figure 4-17. Mixed Air Temperature Control with RA/OA Activated Economizer CLD. 42 Figure 4-18. OA/RA Economizer Differential Setpoint Selection Figure 4-19. Greenville SC Weather Data for OA/RA Economizer Setpoint Selection Example Figure 4-20. Minimum OA Using Two-Position Damper CLD Figure 4-21. Minimum OA Flow CLD Figure 4-22. Supply Duct Static Pressure Control Schematic Figure 4-23. Supply Duct Static Pressure CLD Figure 4-24. Supply Duct Static Pressure Setpoint Reset Figure 4-25. Supply Duct Static Pressure Setpoint Reset, Setpoint Calculation Figure 4-26. Supply Duct Static Pressure Setpoint Reset, Ramp-up / Ramp-down Figure 4-27. Return Fan Flow Control Schematic Figure 4-28. Return Fan Flow CLD Figure 4-29. Air Flows in a Return Fan System Figure 4-30. Primary/Secondary Pumping Control Schematic Figure 4-31. Variable Speed (Secondary) Pump CLD Figure 4-32. Variable Speed (Secondary) Pump Control - Ladder Diagram Figure 4-33. Humidity Control System Schematic Figure 4-34. Humidity Control Sequencing Diagrams Figure 4-35. Cooling and Dehumidification CLD Figure 4-36. Dehumidification / Humidification Sequencing CLD Figure 4-37. Reheat Coil CLD Figure 4-38. Humidifier CLD Figure 5-1. Generic Device Symbols Figure 5-2. Sample Ladder Diagram Figure 5-3. Thermostat and Occupancy Sensor Schedule Figure 6-1. UMCS Decision Flow Chart v

TABLES

Table 5-1: System Reset Button Options and Points Schedule Entries

CHAPTER 1

INTRODUCTION

1-1 BACKGROUND

Designers, installers, and operation 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.

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. 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

• Groundwork for establishment of a non-proprietary and openly accessible ‘point-database’ in support of communications-network management requirements.

The Open database approach further insulates the government from the possibility of single vendor lock-in and resulting proprietary procurement.

1-2 PURPOSE

This UFC is intended to be used with UFGS 23 09 23 (LonWorks® Direct Digital Control for HVAC and Other Local Building Systems). 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. The purpose of this UFC is two-fold;

• Commonality. Describe 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.

• Compatibility. Describe 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.

The Open systems approach described in this UFC is based on ANSI/CEA standard 709.1-B 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.

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 this UFC is necessary because of the variety of approaches that can be used to implement ANSI/CEA-709.1-B where, in the absence of this detail, would very likely result in incompatible systems.

'CEA-709.1' is used in this UFC as the shorthand reference to the ANSI/CEA standard 709.1-B 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-3 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.

The guidance also provides a foundation for the design of other Open building systems.

1-3.1 HVAC control

This UFC provides Open DDC systems guidance for the design of heating, ventilating and air conditioning (HVAC) control systems and other building-level systems, sub-systems and equipment including: primary (air and water) built-up systems, terminal units, and packaged equipment.

1-3.2 Building control network

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

1-3.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 with 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 helps to ensure that the building-level control system is capable of being interconnected with a UMCS. 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.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 can be used to design 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 and accompanying UFGS 25 10 10 'LonWorks Utility Monitoring and Control System' are for use on all USACE and AFCESA projects. The NAVFAC standard is to use BACnet for its DDC communication protocol and NAVFAC systems should use UFGS 23 09 23.13 20 'BACnet Direct Digital Control Systems for HVAC'. NAVFAC allows the use of LonWorks for upgrades and additions to legacy systems.

At the discretion of and with approval from the assigning government agency (such as the responsible Corps of Engineers District) the control system designer may deviate from the approach defined in this UFC. When deviating from this guidance, systems based on an Open communications protocol are recommended and systems that lead to subsequent proprietary procurement or single-vendor systems are discouraged.

1-5 REFERENCES

American National Standards Institute/Consumer Electronics Association:

• ANSI/CEA-709.1-B, Control Network Protocol Specification, 2002

• ANSI/CEA-709.3, Free-Topology Twisted-Pair Channel Specification, 1998.

• ANSI/CEA-852, Tunneling Component Network Protocols Over Internet Protocol

Channels, 2001.

Headquarters, U.S. Army Corps of Engineers (HQUSACE)

• UFGS 25 10 10, LONWORKS® UTILITY MONITORING AND CONTROL

SYSTEM (UMCS), 2008.

• UFGS 23 09 23, LONWORKS® DIRECT DIGITAL CONTROL FOR HVAC AND

OTHER LOCAL BUILDING SYSTEMS, 2008.

• UFC 3-401-01FA, LONWORKS® UTILITY MONITORING AND CONTROL

SYSTEM (UMCS), 2008.

LonMark International

• LonMark Interoperability Guidelines, LonMark Application-Layer Interoperability Guide version 3.4, 2005 and LonMark layer 1-6 Interoperability Guide version 3.4, 2005.

• LonMark XIF Guide, LonMark Device Interface File Reference Guide version 4.401, 2005.

• LonMark SNVT Master List, LonMark Standard Network Variable Type (SNVT) Master List version 12, 2003.

• LonMark SCPT Master List, LonMark Standard Configuration Property Type (SCPT) Master List version 12, 2003.

• LonMark Standard Enumeration Master List, LonMark Standard Enumeration Master List version 12, 2003.

CHAPTER 2

CONTROL SYSTEM NETWORK

2-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 LonWorks® technology and CEA-709.1 communications protocol.

Design of an Open-communications building-level control system does not require an extensive familiarity with the CEA-709.1 protocol, but it is critical that the designer understand that the protocol can be implemented in a manner that is not Open and thus can lead to incompatible systems. Therefore, this chapter contains information pertinent to the design of an Open system that designers likely are not familiar with due to the complex nature of modern networked control systems. While many design decisions have already been made, this chapter describes concepts and selections that the designer should be familiar with when developing a project-specific design.

2-2 ARCHITECTURE

As illustrated in Figure 2-1 a basewide system consists of a UMCS (specified by UFGS 25 10 10) connected to one or more building-level DDC systems (specified by UFGS 23 09 23). The network architecture consists of a basewide IP network and one or more building-level TP/FT-10 networks. DDC UFGS 23 09 23 refers to the building-level TP/FT-10 network as the Building Control Network (BCN). A building point of connection (BPOC) provides an interface between the IP and BCN networks.

Generally, the UMCS will be a basewide system, but it may initially consist of only one (or a few) building control networks with the capability of being expanded to include additional buildings where multiple building control networks can be connected to a single UMCS via a BPOC router at each building.

Figure 2-1. UMCS and DDC System Architecture.

2-3 BUILDING CONTROL NETWORK

2-3.1 General

As illustrated in Figure 2-1 UFGS 23 09 23 specifies the building control network (BCN) and requires the use of CEA-709.1 communications protocol over a TP/FT-10 network (in accordance with CEA-709.3) connected in a doubly-terminated topology. The BCN consists of a backbone with one or more local control buses connected to it via routers.

This produces a logically flat network in the building where each node can communicate directly with any other node without the intervention of another controller.

2-3.2 TP/FT-10 media

TP/FT-10 defines a network media and transceiver type:

• The TP in TP/FT-10 stands for Twisted Pair. This is a description of the media that is used to connect the controllers. In this case, a twisted pair of wires is used. CEA-709.3 requires that this twisted pair meet the requirements of CAT-5

Basewide ANSI 709.1B over IP Network (EIA-852) >=100Mbps

BPOC

Router

RTR

RTR

RTR

More devices and/or ‘subnets’

RTR

More devices.

No more RTRs or

RPTRs

RTR

More devices.

No more RTRs or RPTRs

A N

SI

.1

B o ve r T

P/

FT

-1

(IA

W

A N

SI

.3

One or more workstation running:

-GUI Clients -Network Management Tool Clients -Web Clients (optional)

One or more servers running:

-LNS Server -Network Management Tool -Graphical User Interface (GUI) -Monitoring and Control Software -Web Server (optional)

U

FG

S 23 09 23

UFGS 25 10 10

RTR

non-ANSI 709.1 legacy system

BPOC

Gateway

RTR=Router BPOC=Building Point Of Connection Circle = node (ANSI-709.1 device) cable. While the protocol will work over a variety of cable types, CAT-5 (or better) cable is such a widely used standard that requiring the use of it will help avoid incompatibility problems later.

• The FT in TP/FT-10 stands for Free Topology and indicates the transceiver type that controllers on the network will use. The transceiver is responsible for actually transmitting information across the network. Note that while this allows for Free Topology, the specification further restricts the network to a doubly-terminated bus topology.

• Doubly-Terminated Bus Topology requires that the bus be daisy-chained from one device to another with no branches (stubs under 3 meters in length are allowed in accordance with CEA-709.3) with terminators at both ends of the bus.

The spec requires doubly-terminated bus topology in order to maintain consistency and since this topology is the easiest to understand and work with.

The protocol communicates at 78 kbps, which translates to roughly 250 packets per second before the network begins to saturate. The specification places specific requirements on how the network is structured and how devices communicate on the network to avoid saturating the network.

For very small systems, a single network segment may be sufficient; you will not need a building network backbone. In this case, the specification may be edited manually to remove the requirements for a building backbone Note that there other reasons (explained below) why it might be advantageous to use multiple sub networks in a building.

2-3.3 Other media types

In addition to TP/FT-10, there are two media types that are part of the CEA-709 standard; Power Line (CEA-709.2) and Fiber Optic (CEA-709.4). Furthermore, there are many media/network types available that are not included in the CEA standard.

Many of these media types should be avoided, but some such as Radio Frequency (RF) may be useful in some applications.

The IP network is not part of the BCN therefore UFGS 23 09 23 does specify IP media.

IP networks are specified in UFGS 25 10 10 'Utility Monitoring and Control System'.

2-3.4 Media selection

UFGS 32 09 23 specifies TP/FT-10 because it the most common media and thus the most supported and Open option. 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 alternative media (with the possible exception of Power Line) should only be specified or permitted when it is used in conjunction with TP/FT-10:

• To bridge two TP/FT-10 segments

• As a local control bus connected to a TP/FT-10 backbone

The decision to specify or allow alternative media types is best made by asking “What is gained by using this media instead of TP/FT-10?” and “What Is lost by using this media instead of TP/FT-10”? Often the answer to the first question will be that it is a matter of convenience, while the answer to the second will be that the system will become less Open. In these cases, it is likely worthwhile to proceed with TP/FT-10 despite the additional cost/time, as it will prove to be more convenient in the long term.

In general, if the alternative media type requires installation of the media, then there is likely little or no benefit to using the alternative media. If the alternative media permits use of existing media such as power line (PL), radio frequency (RF) or fiber optic (FO), then it may be justified, but the impact on the Openness of the system must be considered.

Specifying or allowing an alternate media type may be warranted where it is needed to meet bandwidth requirements

2-3.5 Building control network - backbone

In accordance with UFGS 23 09 23 routers are the only devices to be connected to the backbone. In addition, only traffic to/from the front end (via the BPOC) is allowed on the backbone. (Note that these requirements may be relaxed for a very small building.)

This helps to ensure that ample bandwidth is initially available on the backbone and also helps to accommodate bandwidth needs due to system modifications or future expansions. The backbone is available for connection to the UMCS network via BPOC router as specified by UFGS 25 10 10.

In rare cases, the available bandwidth of the building backbone will be insufficient to accommodate the required traffic between the building and the UMCS. In this case the building Contractor will provide a single TP/FT-10 backbone which the UMCS Contractor (not the DDC Contractor) will later break into multiple TP/FT-10 backbones connected by an IP network. A drawback to multiple backbones is that each one requires a BPOC where the BCN is connected to the UMCS network.

Multiple buildings can share a common building-level backbone. For example, two or more adjacent buildings can be physically linked by a common TP/FT-10 backbone as long as network restrictions such as cable length and the total number of nodes as described elsewhere in this UFC and in UFGS 23 09 23 are adhered to. In this case, if the backbone is connected to a UMCS a single BPOC can then be used to connect these buildings to the UMCS. The need for a single BPOC assumes that more than one BPOC is not needed to accommodate network bandwidth usage constraints.

2-3.6 Building control network - local control bus

In accordance with UFGS 23 09 23 the local control bus is the only portion of the BCN where DDC Hardware such as controllers may be connected. This helps to ensure that ample bandwidth is available on the backbone.

2-4 CONNECTION TO A UMCS

The BCN will perform all necessary control functionality in a stand-alone mode but does not provide an operator interface 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, the designer should use the applicable portions of UFGS 25 10 10 to obtain a local monitoring and control system. If the building is to be connected to the UMCS, the UMCS Contractor will be responsible for installation and configuration of the BPOC and integration of the building system into the UMCS.

2-5 NETWORK DESIGN AND LAYOUT

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

UFGS 23 09 23.

2-6 NETWORK HARDWARE

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

2-6.1 Repeater

A repeater is a device that has two or more input/output ports, connects two (or more) pieces of media, and performs signal regeneration. Signals showing up on an input port get cleaned up, amplified, and sent out of the repeaters output port(s). Repeaters may allow for longer cable runs in some cases, but not others.

2-6.2 Media converter

A media converter is a repeater that changes media types (i.e. TP/FT-10 to PL). Use of non-standard media will likely require the use of media converters where the non-standard media connects to another media type or to a device that supports another media type.

2-6.3 Router

A router is similar to a repeater, but performs the additional function of packet filtering based on destination address. A router can look at the destination address of an incoming packet. If the destination DDC Hardware is accessible via media connected to a different output port, the packet will be sent out the appropriate output, otherwise the router will do nothing with the packet.

A router maintains a routing table consisting of a list of the domains and subnets that exist on its output ports. A router typically will also contain a “default” entry, which essentially says “If the destination doesn't show up in any routing table entry, forward the packet to another (specified) device (and hope that device can forward it properly).”

A router may be classified as a configured or learning router. A configured router has its routing tables assigned by the installer. A learning router will “learn” its routing tables. Initially, a learning router simply functions as a repeater and forwards all messages. As messages pass through the router, it looks at the source subnet address and learns which of its input ports connects to that subnet; it can then use that information to build a routing table entry for that subnet. While the choice of learning vs.

configured router is left to the building Contractor, configured routers are generally preferred.

A router provides two very important functions in a control network:

• It greatly reduces network traffic. By placing devices that need to communicate frequently on a common subnet and isolating that section with a router, the base-wide (or UMCS) network will not be bogged down with local communications between the devices on the subnet.

• It allows devices to send messages to a “distant” controller without knowing the detailed network topology. A device that measures and communicates outside air temperature in one building and that sends this outside air temperature measurement to another device in another building only needs to forward the message to its router. The router is then responsible for knowing how to send the message on towards the destination device.

2-6.4 Network bandwidth

In accordance with UFGS 23 09 23 the Contractor is responsible for selecting the details of the architecture and ensuring that the proposed system (devices, network bindings, and network architecture) does not saturate the network.

While it is the Contractors responsibility to design and propose a network that does not exceed the network’s bandwidth capacity, UFGS 23 09 23 provides additional requirements to help ensure those limits are not exceeded:

• Use the UFGS 23 09 23 specified backbone and local control bus 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. Limit “Unacknowledged Send Multiple” and “Send Acknowledged” transmissions to critical data only.

Segmenting the network into local control buses and a backbone is the easiest way to manage network traffic and not overload the network. The intent is to place devices that need to communicate frequently on a common local control bus. The requirement that only routers be connected to the backbone ensures that traffic from a (potentially) congested local control bus does not clog the backbone – the router will keep local traffic on the local control bus and off the backbone. Traffic between devices and the front-end UMCS will utilize the building backbone. The specification requirement that no node has more than two routers between it and the backbone helps ensure that the installer doesn't bog down a local control bus by forcing traffic from a second local control bus to traverse the first local bus to get to the backbone.

2-6.5 Other architecture issues

2-6.5.1 Multiple controllers per HVAC system versus single controller

The LONWORKS industry supports the notion of “distributed control”. In a conventional DDC system, a single relatively powerful controller with ample inputs and outputs is often used to implement a complete sequence of operation. While there are CEA-709.1 controllers that support this approach, another possibility is the use of multiple simpler interconnected controllers. For example, instead of using a single controller to control an air handler, the mixed air dampers may be controlled by a dedicated controller (or even a so-called “smart actuator”) which obtains relevant temperatures from other sensors on the network (“smart sensors”), obtains occupancy status and other information from other devices on the network and drives the dampers. Similarly, the cooling coil valve could be driven by a simple controller whose only output would be a 4- 20 mA control signal to the valve.

While this approach to HVAC control is not necessarily unique to CEA-709.1 based hardware, this approach does seem to be better supported by LONWORKS than other protocol technologies. As with any approach, distributed control has its own set of advantages and disadvantages.

Advantages:

• Simple controllers. Programmable controllers are not needed, which eliminates custom programming and programming software. A small selection of simple controllers can be used for all control schemes. This would allow an installation to standardize on a set of controllers and ease the training requirements for the O&M Staff.

• Supportable by multiple vendors. Since the devices have simple functionality it is easier to find a replacement device from a different vendor with the same functionality.

• Documentation. It is easier to document the actual controller and controller functions/settings.

• No long home-runs of wire. Controllers may be located at the sensors/actuators they interface, or the sensors/actuators may be the controllers (‘smart’ sensors/actuators) which reduced the wiring requirements.

Disadvantages:

• Execution of the system sequence may require communication between multiple controllers which in turn may require a functional network. One work-around to this issue is to create a local control network dedicated to the system and isolate this from the rest of the building with a router (this will protect the local network from most network failures elsewhere in the building).

• Harder to document. While the individual controllers were easier to document, the system sequence may be harder to document since it is distributed among multiple controllers.

• Controllers not in one location. The controllers for a single system may be scattered about the mechanical room, or even outside the mechanical room.

UFGS 23 09 23 places the burden on the Contractor to decide when distributed control should be used.

2-7 ADDRESSING, DATA TRANSMISSION, AND DATA INTEGRITY

2-7.1 Addressing

All network protocols, including CEA-709.1, define an addressing scheme: a method of delivering messages to a specific device on the network. CEA-709.1 defines several such methods. The Domain/Subnet/Node method is shown and used in the current UFGS/UFC criteria. While it requires more care to set up than the use of NodeIDs (another common method) the advantage of the Domain/Subnet/Node method is that the addressing scheme can and should reflect the logical organization of the control network and is therefore more readily managed. For example, a large building may consist of subnets 105 – 110, with a large AHU controller at subnet 108, device 1 and its associated VAV boxes at subnet 108 including devices 2-35. In comparison, if NodeIDs were used, the addresses would all essentially be random numbers between 1 and 281 trillion. The specification requires the use of the Domain/Subnet/Node addressing scheme with documentation of the NodeIDs for DDC Hardware.

The installer should assign the Domain/Subnet/Node address to DDC Hardware according to installation-specific guidelines established for the UMCS. The choice of whether or not to put all devices on a single domain is complex. In concept the use of a single domain base-wide is straightforward, but in practice there are a number of issues to be considered:

• Devices that need to communicate with each other should be on the same domain, as you cannot bind network variables across domains. You can have the front end read a value from a controller on one domain and write it to a different controller on another domain, but this is discouraged. This “limitation” is seldom an issue; controllers that need to talk to each other are generally on the same subnet and almost never required to be on different domains.

• There are performance issues associated with large domains. The network configuration tool will open a 500 device domain faster than it will a 2000 device domain, so in this regard, it is better to have four 500 device domains than one 2000 device domain.

• A typical installation may have a few vendors (say four or five) who install the vast majority of building networks on the installation. While the specification is designed to allow multiple vendors to work with a single base-wide LNS database, there may be advantages to allowing each major vendor to have a separate LNS database (reduced potential for finger pointing, less potential for device renumbering, easier LNS database merging, perhaps easier for building vendors to use their own network configuration tool, etc.). This is not a problem, as the UFGS requires that the Monitoring and Control software support multiple LNS databases. This will require multiple domains, as a single domain cannot span multiple LNS databases.

As a practical matter, any single DDC project will almost certainly use a single domain;

it is highly unlikely that multiple domains will be used within a single contract. The subnet address will often reflect some logical grouping within the system. A single subnet will often suffice for a smaller building; larger buildings may require several subnet addresses. At the lowest level are individual node addresses; each DDC Hardware device on a subnet must have a unique node address.

2-7.2 Data transmission

The CEA-709 data transmission speed is 78.1 kbps and there are 2 primary mechanisms through which data transfer data occurs; polling and binding. 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. Collection of trend data is an example of polling where every 15 minutes a UMCS front-end workstation requests data from several DDC hardware devices. Polling can occur at any time and a device can always poll another device for data.

Binding is used to create another form of data transfer where bindings between one or more devices are set up during network configuration. As a result of binding, a data source sends (on its own initiative) data to a recipient. There are several parameters that control the frequency of this transfer:

• Change of Value (COV). The transmitting device can be configured to only send the data if it changes by a minimum specified amount. For example, a controller that is measuring outside air temperature might be configured to transmit a new temperature value only if the current value changes, from the last value transmitted, by greater than 0.5 degrees. UFGS 23 09 23 requires use of COV whenever possible (some DDC Hardware, particularly ASCs, may not support use of COV in all situations).

• Minimum send time. The transmitting device can be configured not to send the data more often than once every X seconds. This is an important parameter for limiting network traffic; most HVAC control applications (except for example pressure or flow control applications) do not require “real-time” data and therefore data need not be transmitted more often than once every couple of seconds even if it is rapidly changing. UFGS 23 09 23 requires a minimum send time of 5 seconds for traffic between DDC Hardware

• Maximum send time. The transmitting device can be configured to send the data at least once every X seconds, even if the value is not changing. This is generally a good practice just in case something goes wrong. For example, if the receiving device is reset, it may not “remember” older data and therefore may not have the value until it is retransmitted. A typical maximum send time might be 20 minutes. UFGS 23 09 23 requires a maximum send time of 20 minutes for traffic between DDC Hardware

While binding is almost always preferred to polling due to better network efficiency, there are several cases where polling is recommended:

• When the data transmission is of a temporary nature, such as points on a graphic. If the points were bound to the graphic, all points on all graphics would be bound and all the devices would send all the data to the Monitoring and Control server constantly, even if the graphic was not being viewed. By polling, the Monitoring and Control server can request only the data it needs – i.e. data for the graphics pages currently being viewed.

• When the device does not support binding. Frequently, the Monitoring and

Control server and Local Display Panels will not support binding data to them.

In this case, polling is the only option for data transmission.

2-7.3 Data integrity

There are several parameters that govern data integrity: how the protocol ensures reliable data communication with less-than-perfect hardware, noisy lines, “glitches” and other real-world events. With binding, there are several common means to send data and each has advantages and disadvantages:

• Unacknowledged send once. The data is sent one time and one time only. This requires the least network bandwidth, but does not provide any assurance that the data reaches the recipient.

• Unacknowledged send multiple. The data is sent multiple times (typically three).

It is up to the recipient to deal with receiving the same data multiple times. This requires more bandwidth than the send once option but is still fairly fast because the transmitter does not wait for any acknowledgement. It simply sends the data X times and moves on.

• Acknowledged send. The data is sent once. Upon receipt of the data, the receiver must send an acknowledgement message back to the transmitter. If the transmitter does not receive the acknowledgment within a pre-determined period of time (the “timeout”), the transmitter will resend the data. This is the slowest method, but is a good trade-off between reliability and network bandwidth usage.

This is typically used for alarms, where it is essential that the data gets transferred. This is the required method for traffic between DDC Hardware.

(Communication between DDC Hardware is almost always part of a control sequence.)

CHAPTER 3

DIRECT DIGITAL CONTROL HARDWARE AND CONTROL DEVICES

3-1 INTRODUCTION

This chapter describes control devices and the DDC Hardware specified in UFGS 23 09 23 including the extended requirements needed to implement an Open system. It also describes the related terms and concepts pertaining to LONWORKS technology and the underlying CEA-709.1 communications protocol (more commonly known as LonTalk®).

For additional technical information on LONWORKS, see:

https://eko.usace.army.mil/fa/bas/

3-1.1 SNVTs

During inter-communication, nodes share data and information by transmitting and receiving network variables (the messages exchanged between devices). Specifically, UFGS 23 09 23 requires the use of the Standard Network Variable Types (SNVTs) as defined by LonMark International. In general a SNVT is a command, a status, or a variable (such as temperature, pressure, humidity, etc.), but a SNVT can contain other types of information.

3-1.2 Functional profile

LonMark International defines Functional Profiles for LonWorks devices or nodes. A Functional Profile describes standard node communications and consists of mandatory and optional input and output SNVTs, mandatory and optional configuration properties, and finally a manufacturer specific section.

Functional profiles are useful in that they help define communication/data exchange requirements and network interfaces, but they do not go far enough to ensure that devices will interoperate with other devices in accordance with UFGS 23 09 23. At issue is that control sequences in UFGS 23 09 23 require SNVTs that are only optional in the corresponding Functional Profile. Therefore, the Functional Profile, in itself, is not sufficient to ensure that a device has the required inputs/outputs for a specific sequence of operation. Points Schedule drawings, as specified in UFGS 23 09 23, are used to define these extended requirements.

While there is a LonMark Functional Profile available for scheduling of devices, it is unsuitable for the control sequences defined in DDC UFGS 23 09 23 and should not be used.

3-2 DDC HARDWARE

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 are considered DDC Hardware but are not traditionally called controllers even though they may in fact have control functionality (like a feedback control loop). Another term commonly used is “node”, where a LonWorks node is any device that resides on the LonWorks network and communicates via the CEA-709.1 protocol. This includes smart sensors, smart actuators, and controllers, along with a variety of other microprocessor-based devices.

There are several requirements that all DDC hardware must meet. They must:

• Be locally powered: Basically, there are two ways to provide power to a piece of DDC hardware. A link powered device receives its power from the same wire that is used for communication. A local powered device receives its power on a separate set of contacts. Note that a local powered device does not typically include it’s own transformer, the requirement is simply that the device be connected to a local power source, not one over the network. This specification requires that one method be used for consistency and ease of O&M. As the more common and more intuitive option, local power was selected.

• Communicate only using CEA-709.1B

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

• Use a TP/FT-10 transceiver for use on a TP/FT-10 network

• Support 78.1 kbps data transmission

• 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.

• Meet accuracy requirements. Requirements for I/O accuracy are not given directly; instead the requirement is that end-to-end error (i.e. accuracy at the SNVT value) be no worse than 150% of the allowed sensor error. This allows the Contractor flexibility in matching sensor ranges and controller A-to-D converters to the application.

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.

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.

3-2.1 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. This configuration does not change the function of the device, but changes settings within the device such as setpoints and other operational settings. The specification requires that ASCs meet several requirements in addition to the general DDC Hardware requirements. For example:

• An LNS® Plug-in must be provided to…