UFC 3-470-01 UMCS Front End And Integration (12JAN18).pdf

UFC 3-470-01

12 January 2018

UNIFIED FACILITIES CRITERIA (UFC)

APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED

UTILITY MONITORING AND

CONTROL SYSTEM (UMCS)

FRONT END AND INTEGRATION

UTILITY MONITORING AND CONTROL SYSTEM (UMCS) FRONT END AND

INTEGRATION

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

NAVAL FACILITIES ENGINEERING COMMAND (Preparing Activity)

AIR FORCE CIVIL ENGINEER CENTER

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

Change No. Date Location

This UFC supersedes UFC 3-470-01, dated May 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, PhD, PE, PMP, SES

JOSEPH E. GOTT, P.E.

Chief Engineer

Chief, Engineering and Construction Directorate of Civil Works

Naval Facilities Engineering Command

U.S. Army Corps of Engineers

EDWIN H. OSHIBA, SES, DAF MICHAEL McANDREW Deputy Director of Civil Engineers DCS/Logistics, Engineering & Force Protection

Deputy Assistant Secretary of Defense (Facilities Investment and 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-470-01 Utility Monitoring and Control System (UMCS) Front End and Integration, formerly “LonWorks® Utility Monitoring and Control System (UMCS)

Superseding: UFC 3-470-01, dated May 2012

Description: UFC 3-470-01 is revised throughout to address changes in UFGS 25 10 10 and to add support for the BACnet® protocol, Modbus® protocol, DNP®, Niagara Framework® and OPC®. Changes include:

• Changes to the UFC title including removal of the word “LonWorks” and clarification that the UFC covers the UMCS front-end and integration

• Removal of “educational” text not needed to support “instructive” text

• Removal of some LonWorks-specific information

• Addition of information on BACnet, Modbus, DNP®, Niagara Framework and

OPC

• Explanation of the difference between utility control systems and building control systems

• Removal or updating of out-of-date information

Reasons for Document: The changes to UFC 3-470-01 (and to UFGS 25 10 10) were required as a result of the requirements contained in the National Defense Authorization Act of FY2010 (NDAA 2010).

Impact: There are no direct cost impacts to the changes to this UFC. The changes will support the proper design and implementation of UMCS in accordance with UFGS 25 10 10 in support of meeting NDAA 2010 requirements and the procurement of open control systems.

Unification Issues: Due to differences in approach, structure, procurement processes, and technical capabilities some requirements differ between the services. These differences have been documented in this UFC and in UFGS 25 10 10 (using Tailoring Options) and do not pose a barrier to unification.

i

TABLE OF CONTENTS

CHAPTER 1 INTRODUCTION

1-1 BACKGROUND

1-1.1 History

1-1.2 Field Control System Types

1-1.3 Monitoring and Control Software Protocol Support

1-1.4 Open System Definition and Considerations

1-2 PURPOSE AND SCOPE

1-3 APPLICABILITY

1-4 GENERAL BUILDING REQUIREMENTS

1-5 REFERENCES

1-6 GLOSSARY

CHAPTER 2 TECHNICAL REQUIREMENTS

2-1 USE OF UFGS 25 10 10

2-2 TAILORING OPTIONS AND DESIGNER OPTIONS IN UFGS 25 10 10. . 7

CHAPTER 3 UMCS ARCHITECTURE

3-1 GENERAL

3-2 UMCS IP NETWORK

3-3 KEY REQUIREMENTS FOR INTEGRATION

3-4 FIELD CONTROL SYSTEM CONNECTION TO UMCS FRONT END

3-4.1 Direct Connection (Figure 3-1 Case 1)

3-4.2 Control protocol router (Figure 3-1, Case 2)

3-4.3 Control protocol gateway (Figure 3-1, Case 3)

3-4.4 Control protocol gateway (Figure 3-1, Case 4)

3-5 FIELD POINT OF CONNECTION (FPOC)

3-6 FIELD CONTROL SYSTEM

3-6.1 Building Control Systems

3-6.2 Other Field Control Systems

3-7 BASEWIDE UMCS IP NETWORK

3-7.1 Cybersecurity

3-7.2 IT Group Coordination

CHAPTER 4 COMPUTER SOFTWARE

ii

4-1 MONITORING AND CONTROL SOFTWARE

4-1.1 M&C Software Protocol Requirements

4-1.2 M&C Software Licensing Requirements

4-1.3 System Display Graphics Requirement

4-1.4 Standard Reports

4-1.5 Demand Limiting

4-1.6 User Account Management for M&C Software

4-2 USER ACCOUNT MANAGEMENT FOR OTHER COMPUTER

SOFTWARE

4-3 LNS NETWORK CONFIGURATION TOOL (LONWORKS)

4-4 BACNET NETWORK BROWSER (BACNET)

4-5 NIAGARA FRAMEWORK ENGINEERING TOOL

CHAPTER 5 DRAWINGS

5-1 UMCS DRAWINGS OVERVIEW

5-1.1 CONTRACT DRAWING SET

5-2 POINTS SCHEDULE

5-2.1 ALARM CONTACT AND ALARM ROUTING GROUP SCHEDULES .. 22

5-2.2 Alarm Contact Schedule

5-2.3 Alarm Routing Group Schedule

5-3 UMCS EQUIPMENT SCHEDULE

CHAPTER 6 UMCS DESIGN AND IMPLEMENTATION

6-1 INTRODUCTION

6-2 UMCS DESIGN CONSIDERATIONS

6-2.1 Protocol Advantages and Disadvantages

6-2.2 Determine the BCS Protocol Requirements

6-2.3 Determine the UCS Protocol Requirements

6-2.4 Selection of UMCS Protocol

6-2.5 Services Tailoring Option Recommendations

6-3 UMCS DESIGN IMPLEMENTATION

6-3.1 Design Package Requirements

6-3.2 Contracting Mechanisms

APPENDIX A REFERENCES

APPENDIX B EXAMPLE POINTS SCHEDULES

iii

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

FIGURES

Figure 3-1 UMCS Architecture

Figure B-1 Example Points Schedule for LNS-Based LonWorks

Figure B-2 Example Points Schedule for BACnet

Figure B-3 Example Points Schedule for LonWorks with Niagara Framework

Figure B-4 Example Points Schedule for BACnet with Niagara Framework

Figure B-5 Example Points Schedule for Modbus Gateway

Figure B-6 Example Points Schedule for OPC Gateway

TABLES

Table 4-1 Number of Points and Trends in Typical HVAC Systems

Table 5-1 Alarm Contact Schedule

Table 5-2 Alarm Contact Schedule

Table 5-3 UMCS Equipment Schedule iv

This Page Intentionally Left Blank

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 direct digital control (DDC) systems almost since they were introduced in the 1980s. DDC systems are routinely designed and procured on a building-by-building or sub-system by sub-system basis, a process that in the past has often resulted in multiple proprietary systems that will not interoperate with each other. In the absence of specifications and criteria for Open systems, Government procurement rules that require competitive bidding make it extremely difficult if not impossible to procure new DDC systems that are interoperable with existing ones while also being compatible with a base-wide or campus-wide supervisory system.

The introduction of "LonTalk®" and "BACnet®" Open control protocols in the early 1990’s allowed for the procurement of Open and interoperable DDC systems.

1-1.1 History.

In 2004, Unified Facilities Guide Specifications (UFGS) 23 09 23 specifying Open building control systems based on LonWorks technology and a UFGS 25 10 10 specifying a LonWorks-based utility monitoring and control system (UMCS) were released. These specifications covered the use of LonWorks® technology to specify and procure an Open building automation system. In 2010, HR2647, the National Defense Authorization Act of 2010 (NDAA 2010) was passed. Section 2841 of this legislation called for “adoption of an open protocol energy monitoring and utility control system specification” by the Department of Defense. The specification was further required to cover seven different types of systems:

• Utilities and energy usage, including electricity, gas, steam and water usage

• Indoor environments, including temperature and humidity levels

• Heating, ventilating, and cooling components

• Central plant equipment

• Renewable energy generation systems

• Lighting systems

• Power distribution networks

Some of these systems are traditionally considered part of the building automation system (BAS) while others are generally considered to be utility control systems. In order to meet these NDAA 2010 requirements, this UFC and UFGS 25 10 10 -previously LonWorks only - was revised to incorporate support for BACnet®, Modbus®, DNP®, Niagara Framework® and OPC®.

1-1.2 Field Control System Types.

Generally speaking, there are two basic categories of field control system (FCS):

building control systems (BCS) and utility control systems (UCS). BCS systems are generally considered "commercial grade" and are used for applications such as heating and air conditioning, metering, or lighting control. UCS systems are generally considered "industrial grade" and are used for applications where a higher level of reliability and performance (e.g. response time) can justify a higher cost, such as for industrial processes or power distribution. BACnet and “LonTalk” are primarily BCS protocols, Modbus and DNP are primarily UCS protocols and OPC is used for integration of UCS or BCS systems but is not generally considered a “field protocol”.

While the Niagara Framework is focused at the UMCS front end, it also provides support for field devices and field protocols within BCSs and UCSs using a variety of protocols.

1-1.3 Monitoring and Control Software Protocol Support.

Note there is no front end monitoring and control (M&C) software that natively (without some 3rd party hardware device) supports both BACnet and DNP, or both LonWorks and DNP. Because UFGS 25 10 10 must address the integration of HVAC systems using BACnet or LonWorks, there is no option to select DNP as a protocol supported by the front end. As described later in this UFC, DNP systems will be supported through the use of gateways. Of the seven systems required by NDAA 2010, renewable energy generation systems and power distribution networks are expected to use UCS protocols. Central plant equipment and utility metering may use either UCS or BCS protocols, and the remaining systems are expected to use BCS protocols.

1-1.4 Open System Definition and Considerations.

Generally, an Open system is one where there is no future dependence on any one contractor or controls vendor:

• It’s One system - Multiple field systems with controls installed by multiple vendors are integrated into one system

• There is one common front-end that provides users with the capability to interface with all field systems (monitoring, supervisory control, etc.)

• There are a minimum number of vendor-proprietary (software) tools (ideally zero, in practice, a small number) which are required to operate, maintain and modify the system.

• There is no future need for the original (installing) contractor or any particular device manufacturer to perform work on the system

• There is no need for coordination between the installer of the field system and the installer or (or integrator to) the front-end. As long as each contractor follows the appropriate specification the systems will interoperate.

It’s important to note, however, that Openness is not black or white. There is no such thing as a 100% open control system, but UFG 25 10 10 and this UFC, in concert with the building level UFC and specifications (UFC 3-410-02, UFGS 23 09 00, UFGS 23 09 23.01, and UFGS 23 09 23.02) are intended to procure the most open system practical.

Further, an Open system can contain some proprietary components and can have fees, provided the components are a small part of the system and the fees are reasonable

1-1.4.1 Open Building Control Systems.

For building control systems, a flat (one protocol at all levels of the system) single multi-vendor system from the front-end down to the field device can be achieved using LonWorks or BACnet, and UFGS 25 10 10 includes requirements for “top-to-bottom” Openness using these protocols. This includes requirements in the UMCS specification that need complementary requirements in the building control system specification. For example:

• To integrate with a UMCS (front end) based on LonWorks, the building control system has to use only SNVTs and provide an LNS Database.

• To integrate with a UMCS (front end) based on BACnet, the building control system must use only standard BACnet Services and must support a number of BIBBs to allow for configuration of scheduling, alarming and trending functionality from the UMCS.

Niagara Framework does not provide a flat system since the Niagara Framework Supervisory Gateways1 used in the field control systems act as gateways, but it can provide a single multi-vendor system. To integrate with a UMCS (front end) based on the Niagara Framework, a building control system should ideally be installed using the Niagara Framework components. All Niagara components must use an open license which allows multiple vendors to interoperate freely with Niagara components from other vendors.

1-1.4.2 Open Utility Control Systems.

For UCS, Openness from the UMCS all the way to the field controller is not as achievable, and may not be not desirable in some cases. Instead UCS systems are often integrated as distinct “complete systems” (with their own front-end) and use UMCS as a common supervisory front-end. UFGS 25 10 10 can accommodate using the UMCS as the primary front-end for UCS, but the general assumption is that it will serve as a supervisory system in most cases. This is due to many factors, including the increased reliability requirements of the UCS, difference in cybersecurity requirements

1 This device is more commonly known as a “JACE”, which is the name for a specific version of this device. The term “Niagara Framework Supervisory Gateway” is used to remain vendor-neutral.

for the UCS and the UMCS, and because the UCS are often operated by a different organization or group at the garrison than the BCS. In addition, integration of the field control system (with no front-end) to a UMCS is more difficult with utility control systems than with building control systems since the UCS protocols lack data exchange standards compared to LonWorks or BACnet.

1-2 PURPOSE AND SCOPE.

This document describes the design of an Open UMCS Front End and the integration of field control systems into the UMCS, both in accordance with UFGS 25 10 10. This includes hardware, software and, in some cases, networking for the UMCS Front End.

With few exceptions, requirements for field control systems, including controllers, networking, and sequences of operation, are not included in this criteria or UFGS 25 10 10 and are addressed by the relevant field control system criteria and specifications.

The UMCS front end required by this criteria and specified in UFGS 25 10 10 will openly interoperate with systems and subsystems installed in accordance with the building control system specifications (UFGS 23 09 00 Instrumentation and Control for HVAC, UFGS 23 09 23.01 LonWorks® Direct Digital Control for HVAC and UFGS 23 09 23.02, BACnet Direct Digital Control for HVAC). UFGS 23 09 23.01 contains specific requirements, such as the use of LonWorks Network Services (LNS), which provide for open integration to a UMCS installed using the complementary options contained in UFGS 25 10 10. UFGS 23 09 23.02 contains similar specific requirements for a BACnet-based system. Both UFGS 23 09 23.01 and UFGS 23 09 23.02 contain options for use of the Niagara Framework.

1-3 APPLICABILITY.

This UFC and accompanying UFGS 25 10 10 'Utility Monitoring and Control System Front End and Integration' are for use on all Department of Defense projects. At the discretion of and with approval from the assigning government agency (such as the responsible Corps of Engineers District), the design of the UMCS may deviate from the standards defined in this UFC. When deviating from the guidance, systems based on an Open communications protocol are recommended and proprietary procurement or single-vendor systems are discouraged. Without this specific approval, use of both this UFC and the accompanying guidance in UFGS 25 10 10 is mandatory.

UFGS 25 10 10, and the Division 23 controls specifications referenced within, have been adopted in accordance with 10 USC 2867, and exceptions to the requirement for use of these specifications require a waiver from the Secretary of the relevant Service.

1-4 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-5 REFERENCES.

APPENDIX A contains a list of references used in this document.

1-6 GLOSSARY.

APPENDIX C contains acronyms, abbreviations, and terms.

CHAPTER 2 TECHNICAL REQUIREMENTS

2-1 USE OF UFGS 25 10 10.

The implementation of a UMCS Front End and the successful integration of field control systems requires highly specific and prescriptive specifications. UFGS 25 10 10 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 UMCS front end and the specification of integration of field control systems into a UMCS front end must use UFGS 25 10 10 without edits beyond the use of the included tailoring options and designer options.

2-2 TAILORING OPTIONS AND DESIGNER OPTIONS IN UFGS 25 10 10.

The use of tailoring options and designer options in UFGS 25 10 10 must be in accordance with this UFC.

CHAPTER 3 UMCS ARCHITECTURE

3-1 GENERAL.

As illustrated in Figure 3-1, a basewide UMCS consists of a UMCS front end (specified by UFGS 25 10 10) connected to one or more field control systems. These field control systems (FCS) may be building control systems (BCS) – which are generally DDC systems for the control of HVAC, lighting and other building systems - or utility control systems – which vary in composition from “smart relays” to DDC controls to programmable logic controllers (PLC) for control of power distribution or other “industrial” systems. The network architecture consists of a base-wide IP network connected to one or more field control networks. In general, field control networks themselves may use a wide variety of media and protocols, but building control networks for systems based on LonWorks should be a combination of IP, TP/FT-10, and possibly TP/XF-1250. Building control networks for systems based on BACnet should be IP and/or MS/TP. In each case a field point of connection (FPOC) provides an interface between the UMCS IP network and the field control network (FCN).

Generally, the UMCS will be a base-wide system, but it may initially consist of very few, or even only one, field control systems. The UMCS may later be expanded to include additional field control systems. A single UMCS is expected to connect to many field control systems from several or many different vendors, where the field control systems are procured separately and then integrated into the UMCS front end.

3-2 UMCS IP NETWORK.

As specified by UFGS 25 10 10 and as illustrated in Figure 3-1, the UMCS uses a base-wide IP network to support inter-building communication and to serve as the communications link between the field control system(s) and the UMCS computers.

Although this UMCS IP network could be contractor-installed, it will generally be Government Furnished, and this UFC and UFGS 25 10 10 assume the latter. Note that coordination with the installation IT group is critical to ensure that the IP network usage is approved and that cybersecurity for the UMCS has been addressed.

Figure 3-1 UMCS Architecture

3-3 KEY REQUIREMENTS FOR INTEGRATION.

A successful connection between the FCS and the UMCS front end requires two things:

• The UMCS and FCS must use the same protocol (e.g. BACnet, “LonTalk”, other)

• The UMCS and FCS must use the same media. While this is often associated with the protocol (e.g. TP/FT-10 is a LonWorks media type), they are not the same. BACnet uses both IP and MS/TP, and a successful connection requires that both sides use one or the other. Similarly, many incompatible protocols use (can be carried over) IP, so although IP is a protocol, the relevant question isn’t

“use of IP”, but rather “what protocol is being carried over IP”. IP is treated as simply another media type in UFGS 25 10 10 and this UFC.

3-4 FIELD CONTROL SYSTEM CONNECTION TO UMCS FRONT END.

Depending on the FCS, the connection between the FPOC and the FCS may be made via many different means. The primary means of connection are shown in Figure 3-1 and described in the following sub-paragraphs, but there are other, less common possibilities which are not described in this UFC. In addition, there may be additional complexities within the building, additional gateways and control protocol routers.

These details are also not described here – the focus here is how the FCS presents itself to the UMCS.

In some cases, specific hardware may be required for the connection. This hardware may be provided as part of the FCS (case 1, sometimes case 2), otherwise it must be procured as part of integration of the FCS to the UMCS (cases 3 and 4, sometimes case 2). As part of UMCS design, the location and source of this hardware must be determined and shown on the drawings, as well as whether or not the hardware must be provided as part of integration.

3-4.1 Direct Connection (Figure 3-1 Case 1).

When the field control network uses IP (as a media type) and the field control system protocol is supported by the UMCS M&C software, no additional hardware is required and the two systems can be directly connected together.

Strictly speaking, a Niagara building could be considered to be as Case 3 or 4, as the Niagara Framework Supervisory Gateway converts between the building protocol and the UMCS protocol. However, since the Niagara Framework Supervisory Gateway is furnished as part of the building, this detail can be ignored from the perspective of the UMCS, and a Niagara FCS is integrated as in Case 1.

3-4.2 Control protocol router (Figure 3-1, Case 2).

When the field control system protocol is supported by the UMCS M&C software but the field control network does not use IP, a control protocol router (not an IP router) is required to convert the media from the field control network media to IP.

3-4.3 Control protocol gateway (Figure 3-1, Case 3).

When the field control system uses IP but its protocol is not supported by the UMCS M&C software, a gateway is required to convert the FCN protocol to one supported by the UMCS M&C Software.

3-4.4 Control protocol gateway (Figure 3-1, Case 4).

When the field control system does not use IP and its protocol is not supported by the UMCS M&C software, a gateway is required to convert the FCN protocol to one supported by the UMCS M&C Software.

• (Single Device) If a gateway is available that can connect to the field control network media, then a single device may convert both the protocol and the media.

• (Two Devices) If there is no gateway available that can connect to the field control network media, then both a gateway and a control protocol router must be used.

3-5 FIELD POINT OF CONNECTION (FPOC).

A key point in the overall system architecture is the Field Point Of Connection (FPOC), which is the connection point between the portion of the network that is physically dedicated to the control system and the portion of the network that is shared with other applications. The FPOC is important because it:

• Serves as a demarcation point between field-installed network and the UMCS IP network. In many cases, this is also the demarcation point between network owned/managed by the organization operating the facility (Army DPW or other equivalent organization) and the installation IT staff.

• Is a device that, in order to meet cybersecurity requirements, should be secured to limit traffic between the two network pieces.

The FPOC is typically a switch owned and managed by the installation IT staff. As such, it is largely transparent to the UMCS; it is part of the IP network provided by the installation IT staff. It is included here because of its important role in cybersecurity for the system.

3-6 FIELD CONTROL SYSTEM.

A Field Control System (FCS) is a networked system of controllers operating to control a building, a portion of a building, or a utility system. The terms Field Control System and Field Control Network refer to both Building Control Systems/Networks and Utility Control Systems/Networks. A FCS is generally installed as a single project and is intended to provide a complete stand-alone solution for the control of the underlying equipment, though it may lack a full-featured operator interface. From the perspective of integration to the UMCS front end, the underlying details of the FCS are not important;

the integration of a FCS into the UMCS will be accomplished using one of the cases discussed above and shown in Figure 3-1.

3-6.1 Building Control Systems.

Building control systems installed in accordance with UFGS 23 09 00 (and UFGS 23 09

23.01 or UFGS 23 09 23.02) are described in those specifications and in UFC 3-410-02.

3-6.2 Other Field Control Systems.

Other field control systems, whether they are building control systems using other protocols or utility control systems, will generally not result in a flat network. In these cases it is generally expected that the connection between the UMCS and FCS will be through a gateway or through a supervisory controller/interface provided as part of the field control system. For Niagara Framework based UMCS, it is expected that these control systems will be integrated through the use of Niagara Framework Supervisory Gateways. Ideally, the gateways are installed as part of the FCS project, otherwise they must be installed during integration.

Note that for some systems, the connection between the FCS and UMCS may be via a FCS local front-end; for example, a FCS which uses a protocol not supported by the UMCS front end may have a FCS front end that has a software driver for BACnet, LonTalk, or OPC.

3-7 BASEWIDE UMCS IP NETWORK.

3-7.1 Cybersecurity.

Cybersecurity is an ever-changing area, and the guidance provided here may no longer be current or applicable. Further, the different Services have different approaches to cybersecurity for UMCS and it’s vital to coordinate cybersecurity requirements 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 UMCS. For the Army, UMCS design, including cybersecurity, should be coordinated with the UMCS Mandatory Center of Expertise (MCX) at Huntsville.

In general, the UMCS front end will not be considered a mission critical system to the installation. Individual controls within a building control system are designed to run stand-alone without intervention from a UMCS front end. Guidance on handling critical systems as part of a UMCS is in UFC 4-010-06, Cybersecurity of Facility-Related Control Systems.

3-7.1.1 [Army] Certificates of Networthiness.

Army regulations require that any application or system connected to the basewide network have a Certificate of Networthiness (CoN). Installations may reference a pre-existing Networthiness certificate developed by another installation as long as the application is the same (vendor and release) and the existing certificate is not of the “limited” type and therefore can be used Army-wide. UFGS 25 10 10 includes a requirement for the contractor to either provide a valid CoN or submit a completed CoN application for use by the installation in obtaining a CoN. Further information is available at the Networthiness website2 at:

https://army.deps.mil/netcom/sites/nw/CoNApproval/Lists/Networthiness%20Data/NWP ublicView.aspx.

2 This website requires CAC authentication.

https://army.deps.mil/netcom/sites/nw/CoNApproval/Lists/Networthiness%20Data/NWPublicView.aspx https://army.deps.mil/netcom/sites/nw/CoNApproval/Lists/Networthiness%20Data/NWPublicView.aspx

The UMCS Mandatory Center of Expertise (MCX) at Huntsville can assist with addressing CoN and should be contacted for advice and support during UMCS design.

3-7.2 IT Group Coordination.

Coordination with the IT Group is critical to address cybersecurity as well as other aspects of UMCS operation. Some key points of coordination are described here.

3-7.2.1 Computer Selection, Administration and Maintenance.

It may be advantageous (or in some cases required) for the IT group to manage day-to-day operation of UMCS computer servers including backups, account management, operating system and security updates, and other administration tasks. At the very least, the IT group will likely have specific requirements for computers connected to the basewide network

Some UMCS software, the M&C Software in particular, will have specific requirements for the configuration of the computers it operates and may also have certain requirements or limitation on the upgrades and patches that can be applied to the operating system without also updating the software. In addition, there may be certain patches or updates that cause the web browser based client to fail when they are applied to client machines. Coordination with the IT group to ensure that computers vital to the operation of the UMCS aren’t patched or updated without coordination between the organization operating the UMCS and the IT group is critical.

3-7.2.2 UMCS Network Bandwidth.

A properly designed UMCS Network will require minimal network bandwidth as compared to many IT applications and compared to the bandwidth typically available on a modern basewide IT backbone. The IT group, however, will likely require assurances of this. UFGS 25 10 10 requires that the contractor provide a network bandwidth estimate. The purpose of this estimate it to provide documentation of a “ballpark” for bandwidth use that can be provided to the IT group. The UFGS does not provide specific guidance on how to calculate this estimate and instead require the contractor to use their understanding of the M&C Software they are installing and the M&C Software licensing and performance requirements to estimate the overall bandwidth usage.

CHAPTER 4 COMPUTER SOFTWARE

4-1 MONITORING AND CONTROL SOFTWARE.

The Monitoring and Control (M&C) software uses a client-server model with web-browser based clients. The UFGS specifies M&C Software functionality. Some vendors cannot implement all of this functionality in their standard server-based software, and the UFGS permits some functionality – specifically point calculations and demand limiting – to be performed by controller hardware. The software operating on the controller hardware to perform these functions is still considered M&C Software and is included in all M&C Software requirements such as licensing. In addition, any software required to set up this controller hardware must be provided.

4-1.1 M&C Software Protocol Requirements

UFGS 25 10 10 makes use of SpecsIntact Tailoring Options which allow for customization by the designer of requirements for protocol support by the Monitoring and Control (M&C) Software. Including a tailoring option – BACnet, LonWorks, Modbus, OPC, or Niagara Framework - will require support for that protocol or technology by the UMCS M&C Software. Careful consideration must be used in determining which tailoring options to include:

• Selection of a specific protocol will require that the M&C software support that protocol and that integration of buildings supporting that protocol be via that protocol (there could be cases where there are multiple options for integration).

• Any protocol (whether selected or not) may always be integrated, either by direct support of that protocol by the M&C software (e.g. integration of a Modbus FCS where the front end was required to support LonWorks but also provided a Modbus driver) or through the use of a hardware gateway.

Careful selection of appropriate tailoring options is critical to avoid creating conflicting, confusing or impossible to meet requirements. Additional guidance on the selection of tailoring options can be found in 0 This Page Intentionally Left Blank

UMCS DESIGN AND IMPLEMENTATION.

4-1.2 M&C Software Licensing Requirements

M&C software packages have upper capacity limits on the number of points, alarms, etc. that the package can accommodate. In addition, many packages have licenses that further limit the capacity to less than the maximum supported by the software. The designer must specify the number of network points and number of alarms, trends, and occupancy schedules required for the installation. These requirements are determined by two factors:

• The number of points, alarms, trends, and schedules required for a specific system or sequence of operation and

• The number of systems to be ultimately integrated into the UMCS

The former number can be calculated quite accurately (e.g. “this AHU needs 37 points”), however this is seldom worth the effort given the large uncertainties in the ultimate size of the UMCS (e.g. will the UMCS contain 200 AHUs, or 2000?).

4-1.2.1 Number of Points

Table 4-1 provides very rough estimates of the number of points and long-term trends for typical HVAC systems.

Table 4-1 Number of Points and Trends in Typical HVAC Systems

System Points Trends

Terminal unit (fan coil, VAV box, etc.) 5 - 15 1 - 5

Small packaged AHU 20 -30 4 - 8

Medium built-up AHU 25 – 50 10 - 15

Large complex AHU 30 – 60 15 - 20

Small package chiller or boiler 10 – 20 5 – 15

Large central plant chiller 30 – 60 20 – 30

Large central plant boiler 20 – 40 15 - 25

Hydronic pumping system 15 – 25 5 - 10

More accurate numbers could be obtained from sequence specific point schedules, but effort should be focused on determining the actual number of systems as that will drive the licensing requirements.

4-1.2.2 Number of schedules

If the only protocol tailoring option selected is BACnet or Niagara Framework there is no need for a requirement in the UFGS relating to number of schedules since scheduling occurs within the building control system. Similarly, if only the LonWorks tailoring option is used and the UMCS is connecting only to new building control systems installed in accordance with UFGS 23 09 00 and UFGS 23 09 23.01, scheduling will be performed within the building control system and there is no need to require that the UMCS front end perform scheduling.

When using other tailoring options (or when using LonWorks to connect to older building control systems which do not use the “Simple Scheduler” functional profile), specify the required number of schedules. A very conservative estimate would be one schedule per system (AHU, or AHU and its associated VAV boxes) and one schedule per X number of stand-alone terminal units which can operate on a common schedule, where X is determined from the design. In practice, though, it is expected that multiple systems (in multiple buildings) will operate from a common schedule so the total required number of schedules should be much less than this conservative estimate. Coordinate with the site to determine their approach to scheduling. If the site indicates they operate systems according to common schedules, the “default” recommendation in the guide spec should be more than sufficient.

4-1.2.3 Number of clients

An important decision that the designer must make in coordination with the installation (customer) is the number of client seats desired. Most M&C software will be licensed as a single server but with varying numbers of client (these may be referred to as client “seats”). UFGS 25 10 10 requires web-browser based clients, so the limit on the number of clients is the total number of simultaneous clients.

4-1.3 System display graphics requirement.

The term Graphical User Interface (GUI) is somewhat a misnomer. An operator thinks of a GUI as providing a graphical representation of systems (i.e. pictures) whereas vendors use the term GUI in the same sense that Microsoft® describes Excel®, as providing a GUI for a spreadsheet (tool bars, pull down menus, mouse driven, etc.).

This can potentially lead to a Contractor providing a GUI without graphics. Most vendors offer some level of graphical representation of systems; whether these graphics are included in the base-level product offering depends on the vendor. Most vendors also offer animation, 3-D graphics, links to AutoCAD or PDF documents, and links to GIS (Geographical Information Systems).

4-1.3.1 System display graphics detail level.

UFGS 25 10 10 requires a moderate level of graphics including building floor plans and either one-line or 3-D representation of HVAC systems. These requirements must be edited in accordance with the specific site requirements. It’s important to consider the effect that detailed graphics have on the performance of the user interface; the more complex the graphic, particularly interactive graphics, the longer it will take for the page to load.

4-1.3.2 Cybersecurity issues related to graphics.

It is important to note that many vendors make extensive use of Java, JavaScript, Flash, Shockwave, Silverlight, and ActiveX controls; all of these technologies have important IA ramifications. UFGS 25 10 10 requires that the system function using only Java, Shockwave, Silverlight, Flash, and specifically prohibits use of ActiveX. These issues should be carefully coordinated with site cybersecurity personnel and with the requirements of UFC 4-010-06 and UFGS 25 05 11.

4-1.4 Standard reports.

UFGS 25 10 10 requires an extensive list of reports. Coordinate with the installation and edit these requirements as needed.

4-1.5 Demand limiting.

UFGS 25 10 10 requires that the M&C Software be capable of performing electrical demand limiting. While the installation may not implement demand limiting immediately, trends in energy pricing and government energy targets make its eventual use likely.

The UFGS includes a designer option to require the use of real time pricing data for demand limiting. While most vendors provide some demand limiting functionality, it may be difficult to get demand limiting incorporating real time pricing at this time. In addition, the use of real time pricing requires a connection to an external server (via the Internet), which introduces vulnerabilities into the system and makes meeting cybersecurity requirements more difficult. Unless specifically required by the site, it is recommended that the requirement for real time pricing not be included.

4-1.6 User account management for M&C software.

UFGS 25 10 10 requires that the M&C Software includes the ability to create and manage user accounts for itself. In addition, it includes a requirement that the M&C Software support a Common Access Card (CAC) login, although implementation of this may not be required for all projects.

4-2 USER ACCOUNT MANAGEMENT FOR OTHER COMPUTER

SOFTWARE.

While other computer software required by UFGS 25 10 10 may have user accounts and privileges similar to the M&C software, more often the full capabilities of the software will be available to anyone with access to the software (i.e. there may not be a specific login screen within the software package). For example, an in general, anyone who can run the LNS Network Configuration Tool or ASHRAE-135 Network Browser will be able to perform any operation allowed by that software. For this reason, care should be taken when assigning Microsoft® Windows® user accounts to machines that contain this software to prevent an unauthorized user from being able to damage the system.

4-3 LNS NETWORK CONFIGURATION TOOL (LONWORKS).

The LNS network configuration tool is used to configure communication between controllers and to set device configuration properties such as PID loop settings and setpoints. So that the installation can become proficient with one tool and to avoid multiple tools, UFGS 25 10 10 requires the tool be provided as a part of UMCS contract rather than asking for a tool from each building control system contractor.

Coordinate with the site to determine how many copies of the LNS Network Configuration Tool are required and where they are to be installed. In general, one copy of the LNS Network Configuration Tool should always be installed on the M&C Software Server, but additional installation on laptops may be needed by the maintenance staff. Show these requirements on the UMCS Equipment Schedule.

4-4 BACNET NETWORK BROWSER (BACNET)

The BACnet Network Browser provides the capability to look at, read values from and write values to a BACnet network. While the M&C Software will also have this functionality, the BACnet Network Browser can be installed on a laptop and used by maintenance staff in the field even when the building control system is not connected to the UMCS IP network, or when a local interface is beneficial.

Coordinate with the site to determine how many copies of the BACnet Network Browser are required and where they are to be installed. Show these requirements on the UMCS Equipment Schedule.

4-5 NIAGARA FRAMEWORK ENGINEERING TOOL

The Niagara Framework engineering tool is software used to program and configure all aspects of the Niagara Framework including both Niagara Framework Supervisory Gateways and the Niagara Framework M&C software. It also provides network management and device configuration capabilities for Niagara Framework devices. It is available from multiple vendors, but requires additional licensing requirements for an open implementation (to ensure a tool from one vendor will function with Niagara Framework components from a different vendor). The tool, along with the specific licensing requirements, is specified in UFGS 25 10 10, as well as UFGS 23 09 23.01 and UFGS 23 09 23.02 (though it will typically be procured under UFGS 25 10 10).

CHAPTER 5 DRAWINGS

5-1 UMCS DRAWINGS OVERVIEW.

This chapter describes typical UMCS design drawing requirements and how to edit them to be project-specific. CHAPTER 6 UMCS DESIGN AND IMPLEMENTATION provides an overview of the project-specific drawing requirements detailed in this chapter. Example drawings in Microsoft Excel format can be found at the “UFGS Forms, Graphics and Tables” page of the Whole Building Design Guide (WBDG) website: http://www.wbdg.org/ffc/dod/unified-facilities-guide-specifications-ufgs/forms-graphics-tables

5-1.1 CONTRACT DRAWING SET.

5-1.1.1 Contract drawing set contents.

A set of Contract drawings must include:

• Points Schedule(s)

• Points Schedule - Contractor Instructions

• Alarm Contact Schedule

• Alarm Routing Group Schedule

• UMCS Equipment Schedule

• Demand Limiting Schedule (if demand limiting is implemented)

• Occupancy Schedules

5-1.1.2 Editing contract drawings.

As part of the editing process to make the sample drawings project-specific, the sample drawings use the following conventions:

• Entries required of the designer are shown bracketed as: [ ___ ]

• Entries required of the UMCS Contractor are shown bracketed as: < ___ >

• Spaces where no entry is ordinarily required contains a tilde: “ ~ “ (equivalent to an “n/a” or null value)

The bracketed ([ __ ]) designer entries in the sample drawings are provided as a guide to the designer, and must be verified or changed during design. When editing the drawings, delete the brackets after verifying/providing the entry. Contract drawings must http://www.wbdg.org/ffc/dod/unified-facilities-guide-specifications-ufgs/forms-graphics-tables http://www.wbdg.org/ffc/dod/unified-facilities-guide-specifications-ufgs/forms-graphics-tables contain no designer brackets [ ___ ]; entries requiring information from the contractor are shown in “<___>” brackets. When appropriate, designer brackets may be replaced with contractor brackets during design. Do not leave cells blank. Instead, show the tilde ("~") to indicate a null value or that no further entry is required.

5-2 POINTS SCHEDULE.

The most common task to be performed under UFGS 25 10 10 is integration of one or more field control systems into a UMCS (new or existing), and the designer must include Points Schedule drawing(s) in the UMCS contract package to specify integration requirements. Whenever possible, these Points Schedules should be obtained from the as-built submittals of completed field control system projects, particularly when UFGS 23 09 23.01 or UFGS 23 09 23.02 was used.

Detailed point schedule instructions are in UFC 3 410 02 Direct Digital Control for HVAC and Other Local Building Systems.

5-2.1 ALARM CONTACT AND ALARM ROUTING GROUP SCHEDULES.

The M&C software will route alarms according to the alarm routing group shown on the Points Schedule. The alarm routing group is defined by the use of two separate schedules: an Alarm Contact Schedule that lists information on specific individuals and an Alarm Routing Group Schedule that defines the actions to be taken for each “route”.

5-2.2 Alarm contact schedule.

The Alarm Contact Schedule, shown in Table 5-1, defines alarm recipient information.

The designer must either complete this schedule or specify that the Contractor must complete this schedule. In either case, customer input is required to identify appropriate entries.

Table 5-1 Alarm Contact Schedule

PERSONS

NAME

EMAIL ADDRESS

TEXT MESSAGE

ADDRESS

DESCRIPTION

5-2.3 Alarm routing group schedule.

The Alarm Routing Group Schedule (shown in Table 5-2), defines actions to be taken for an alarm based on alarm routing groups. Each alarm routing group specifies the destinations for the alarm message and is some combination of the following:

• Pop-up a message on all open clients

• Send as email to one or more individuals

• Send a text message via email to one or more individuals

• Print to one or more printers

The designer must either complete this schedule or specify that the Contractor must complete this schedule. In either case, input from the project site is required to identify appropriate entries. Each row in this schedule specifies a unique alarm routing group, and each group may be used by multiple alarms. Individual cells may have multiple entries (e.g. one routing group may email to multiple individuals). Alarms are assigned to routing groups in the M&C Routing column of the Points Schedule.

Table 5-2 Alarm Contact Schedule

5-3 UMCS EQUIPMENT SCHEDULE.

The UMCS Equipment Schedule, Table 5-3, shows requirements for UMCS equipment such as FPOCs (routers, gateways), Control Protocol Network Hardware, computer servers, computer workstations and printers. The schedule contains the following information (by column heading):

• Reference: Complete this field by entering an equipment identifier.

• Hardware: Complete this field for each piece of hardware furnished by the Government or required of the Contractor.

o Computer: List each Server and each Workstation (Desktop or Laptop).

ROUTING

NAME

EMAIL TO

TEXT MESSAGE

TO

POP-UP

PRINT TO

PRINTERS

o Printer: List each printer by type - Alarm (continuous feed is default), Laser (B&W), or Color.

o FPOC: List each Control Protocol Router and each Gateway.

o The Contractor will add entries for other hardware such as each M&C Software Controller Hardware and each BACnet Supervisory Controller Hardware.

• Hardware Provided By: Complete this field to indicate whether the hardware is contractor-provided or Government-furnished.

• Hardware Location: Show the location the hardware is installed or must be installed in.

• Network Name: The Contractor completes this field.

• IP Address: The Contractor completes this field.

• Media Size or Monitor Size: Show the display monitor size for computers or non-standard media size for printers. UFGS 25 10 10 requires all printers be able to print on 8.5 inch by 11 inch portrait mode media. List any other media sizes required here.

• Note that the…