W911SA-18-B-2021_Attachment_8_251000_Utility_Monitoring.pdf

Army Reserve Center, Phase II W912QR-15-C-0044 Riverside, California Certified Final Design / For Construction

SECTION 25 10 10

UTILITY MONITORING AND CONTROL SYSTEM (UMCS) FRONT END AND INTEGRATION

11/15

PART 1 GENERAL

1.1 SUMMARY

Provide a Utility Monitoring and Control System (UMCS) which performs supervisory monitoring and supervisory control of base-wide building control systems and utility control systems using one or more of:

ASHRAE 135 (BACnet), Modbus, OPC DA, or the Niagara Framework with Fox protocol as indicated and shown. Integrate field control systems installed per or Section 23 09 23.02 BACNET DIRECT DIGITAL CONTROL FOR HVAC AND OTHER BUILDING CONTROL SYSTEMS to the UMCS via Niagara Framework Supervisory Gateways as specified. Integrate ASHRAE 135 (BACnet) field control systems installed per Section 23 09 23.02 BACNET DIRECT DIGITAL CONTROL FOR HVAC AND OTHER BUILDING CONTROL SYSTEMS as specified.

1.1.1 System Requirements

Provide a UMCS as specified and indicated, and in accordance with the following characteristics:

1.1.1.1 General System Requirements

a. The system performs supervisory monitoring and control functions including but not limited to Scheduling, Alarm Handling, Trending, Overrides, Report Generation, and Electrical Demand Limiting as specified.

b. The system includes a Graphical User Interface which allows for graphical navigation between systems, graphical representations of systems, access to real-time data for systems, ability to override points in a system, and access to all supervisory monitoring and control functions.

c. All software used by the UMCS and all software used to install and configure the UMCS is licensed to and delivered to the installation.

d. All necessary documentation, configuration information, configuration tools, programs, drivers, and other software is licensed to and otherwise remains with the Government such that the Government or their agents are able to repair, replace, upgrade, and expand the system without subsequent or future dependence on the Contractor.

Software licenses must not require periodic fees and must be valid in perpetuity.

e. Provide sufficient documentation and data, including rights to documentation and data, such that the Government or their agents can execute work to repair, replace, upgrade, and expand the system without subsequent or future dependence on the Contractor.

f. The UMCS interfaces directly to ASHRAE 135, CEA-709.1-D , Modbus, OPC DA, and Niagara Framework field control systems as specified and may

SECTION 25 10 10 Page 1 rickey.johns Highlight rickey.johns Highlight rickey.johns Highlight rickey.johns Highlight interface to field control systems using other protocols via an M&C Software protocol driver or a Gateway.

g. For UMCS systems with Monitoring and Control Software functionality implemented in Monitoring and Control (M&C) Controller Hardware, provide sufficient additional controller hardware to support the full capacity requirements as specified.

h. All Niagara Framework components have an unrestricted interoperability license with a Niagara Compatability Statement (NiCS) following the Tridium Open NiCS Specification and have a value of "ALL" for "Station Compatibility In", "Station Compatability Out", "Tool Compatability In" and "Tool Compatability Out". Note that this will result in the following entries in the license.dat file:

accept.station.in="*" accept.station.out="*" accept.wb.in="*" accept.wb.out="*"

i. The version of Niagara Framework used on this project must be Version

4.0 or later.

1.1.1.2 BACnet Requirements

a. The UMCS must communicate using ASHRAE 135 Annex J over the Government furnished IP network as specified.

b. All communication between the UMCS and ASHRAE 135 field control networks must be via the ASHRAE 135 protocol over the IP network.

c. All communication between the M&C Software and the field control system devices must be via standard ASHRAE 135 services other than PrivateTransfer and ConfirmedPrivateTransfer except as follows:

(1) PrivateTransfer and ConfirmedPrivateTransfer may be used for device configuration and device programming.

(2) PrivateTransfer and ConfirmedPrivateTransfer may be used for communication between the M&C Software and the field control system if and only if both the M&C Software and the field control system devices automatically (without requiring reconfiguration) revert to the use of other standard ASHRAE 135 services when one of the components is modified or replaced.

1.1.1.3 Modbus Requirements

The UMCS must communicate using Modbus TCP/IP over the Government furnished IP network as specified.

Modbus communications must support all of the following Modbus data types:

a. The four standard data types defined by Modbus: Discrete Inputs, Coils, Input Registers, and Holding Registers. (Note that these four data types are included in the Modbus standard. The remaining data types indicated in this Section are not included in the Modbus standard but are defined by this Section to provide a standard for communication between systems.)

b. Character: Character data using a single Input Register or single

SECTION 25 10 10 Page 2 rickey.johns Highlight

Holding Register where that Modbus register is interpreted as two 8 bit ISO 8859-1 characters, with the low order bits representing the right-hand character.

c. Floating Point: Floating point data using two consecutive Input Registers or two consecutive Holding Registers where the resulting 32 bits are interpreted as a Binary32 (Single Precision Floating point) number as specified in IEEE 754 . Use the first Register for the higher 16 bits, and the second Register for the lower 16 bits.

d. Integer Date: Date data using three consecutive Input Registers or three consecutive Holding Registers where the resulting 48 bits are interpreted as a 48-bit unsigned big-endian integer. The value is the number of milliseconds, not including leap seconds, from 1970-01-01T00:00:00.000 (12AM, January 1, 1970). Use the first Register for the highest 16 bits and the third Register for the lowest 16 bits.

e. Character Date: Date data using the format specified in IETF RFC 5545 and ISO 8601 of "YYYY-MM-DDTHH:MM:SS.SSS", where the individual characters are formatted as specified for character data.

1.1.1.4 OPC Requirements

The UMCS must communicate using OPC DA over the Government furnished IP network as shown and specified.

1.1.1.5 Niagara Framework Requirements

The UMCS must use the Niagara Framework and must communicate with Niagara Framework field control systems using the Fox protocol over the Government furnished IP network as indicated and specified.

1.1.2 General Cybersecurity Requirements

Address cybersecurity in accordance with DA AR 25-2 .

1.1.3 Symbols, Definition and Abbreviations

Use symbols, definitions, and engineering unit abbreviations indicated in the contract drawings for displays, submittals and reports. For symbols, definitions and abbreviations not in the contract drawings use terms conforming at a minimum to IEEE Stds Dictionary and the ASHRAE FUN IP , as applicable.

1.1.4 System Units and Accuracy

Use English (inch-pound) units for displays, print-outs and calculations.

Perform calculations with an accuracy of at least three significant figures. For displays and printouts present values to at least three significant figures.

1.1.5 Data Packages/Submitals Requirements

Technical data packages consisting of computer software and technical data (meaning technical data which relates to computer software) which are specifically identified in this project and which may be defined/required in other specifications must be delivered strictly in accordance with the CONTRACT CLAUSES and in accordance with the Contract Data Requirements

SECTION 25 10 10 Page 3

List, DD Form 1423. Data delivered must be identified by reference to the particular specification paragraph against which it is furnished. All submittals not specified as technical data packages are considered shop drawings under the Federal Acquisition Regulation Supplement (FARS) and must contain no proprietary information and must be delivered with unrestricted rights.

1.2 REFERENCES

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

AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI)

ANSI INCITS 154 (1988; R 2004) Office Machines and Supplies - Alphanumeric Machines - Keyboard Arrangement

AMERICAN SOCIETY OF HEATING, REFRIGERATING AND AIR-CONDITIONING

ENGINEERS (ASHRAE)

ASHRAE 135 (2012; Addenda AR 2013; Errata 1 2013; INT 1-9 2013; Errata 2 2013; INT 10-12 2014;

Errata 3-4 2014; Addenda AI-AY 2014; INT 13-19 2015; Errata 5 2015) BACnet—A Data Communication Protocol for Building Automation and Control Networks

ASHRAE FUN IP (2013; Addenda and Corrigendum 2013) Fundamentals Handbook, I-P Edition

CONSUMER ELECTRONICS ASSOCIATION (CEA)

CEA-709.1-D (2014) Control Network Protocol Specification

CEA-709.3 (1999; R 2004) Free-Topology Twisted-Pair Channel Specification

CEA-852-C (2014) Tunneling Component Network Protocols Over Internet Protocol Channels

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE)

IEEE 1815 (2012) Electric Power Systems Communications-Distributed Network Protocol (DNP3)

IEEE 754 (2008) Floating-Point Arithmetic - IEEE Computer Society

IEEE 802.11 (2012; AA 2012; AE 2012; AD 2012; AC 2013;

AF 2013) Information technology-Telecommunications and Information Exchange Between Systems Local and Metropolitan Area Networks-Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer

SECTION 25 10 10 Page 4

(PHY) Specifications

IEEE C62.41 (1991; R 1995) Recommended Practice on Surge Voltages in Low-Voltage AC Power Circuits

IEEE Stds Dictionary (2009) IEEE Standards Dictionary: Glossary of Terms & Definitions

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO)

ISO 8601 (2004) Data Elements and Interchange Formats - Information Interchange - Representation of Dates and Times

ISO 8859-1 (1998) Information Technology - 8-Bit Single-Byte Coded Graphic Character Sets - Part 1: Latin Alphabet No. 1

INTERNET ENGINEERING TASK FORCE (IETF)

IETF RFC 4361 (2006) Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)

IETF RFC 5545 (2009) Internet Calendaring and Scheduling Core Object Specification (iCalendar)

IETF RFC 7465 (2015) Prohibiting RC4 Cipher Suites

RFC 821 (2001) Simple Mail Transfer Protocol (SMTP)

LONMARK INTERNATIONAL (LonMark)

LonMark Interoperability Guide (2005) LonMark Application-Layer Interoperability Guide and LonMark Layer 1-6 Interoperability Guide; Version 3.4

LonMark SNVT List (2003) LonMark SNVT Master List; Version

LonMark XIF Guide (2001) LonMark External Interface File Reference Guide; Revision 4.402

MODBUS ORGANIZATION, INC (MODBUS)

Modbus (2006) Modbus Application Protocol Specification; Version 1.1b and Modbus Messaging on TCP/IP Implementation Guide;

Version V1.0b

NATIONAL ELECTRICAL MANUFACTURERS ASSOCIATION (NEMA)

NEMA 250 (2014) Enclosures for Electrical Equipment (1000 Volts Maximum)

NATIONAL FIRE PROTECTION ASSOCIATION (NFPA)

NFPA 262 (2015) Standard method of Test for Flame

SECTION 25 10 10 Page 5

Travel and Smoke of Wires and Cables for Use in Air-Handling Spaces

NFPA 70 (2014; AMD 1 2013; Errata 1 2013; AMD 2 2013; Errata 2 2013; AMD 3 2014; Errata 3-4 2014; AMD 4-6 2014) National Electrical Code

OPC FOUNDATION (OPC)

OPC DA (2002) OPC Data Access (DA) Specification;

Version 2.05a

TELECOMMUNICATIONS INDUSTRY ASSOCIATION (TIA)

TIA-568-C.1 (2009; Add 2 2011; Add 1 2012) Commercial Building Telecommunications Cabling Standard

TIA-606 (2012b; Add 1 2015) Administration Standard for the Telecommunications Infrastructure

TIA-607 (2011b) Generic Telecommunications Bonding and Grounding (Earthing) for Customer Premises

TRIDIUM, INC (TRIDIUM)

Niagara Framework (2012) NiagaraAX User's Guide

Tridium Open NiCS (2005) Understanding the NiagaraAX Compatibility Statement (NiCS)

U.S. ARMY (DA)

DA AR 25-2 (2007; RAR 2009) Information Assurance

U.S. FEDERAL COMMUNICATIONS COMMISSION (FCC)

FCC EMC (2002) FCC Electromagnetic Compliance Requirements

FCC Part 15 Radio Frequency Devices (47 CFR 15)

UNDERWRITERS LABORATORIES (UL)

UL 1778 (2014; Reprint Aug 2015) Uninterruptible Power Systems

UL 60950 (2000; Reprint Oct 2007) Safety of Information Technology Equipment

1.3 DEFINITIONS

The following list of definitions may contain terms not found elsewhere in this Section but are included here for completeness. Some terms are followed with a protocol reference in parenthesis indicating to which protocol the term and definition applies. Inclusion of protocol-specific

SECTION 25 10 10 Page 6 definitions does not create a requirement to support that protocol, nor does it relax any requirements to support specific protocols as indicated elsewhere in this section."

1.3.1 Alarm Generation

The process of comparing a point value (the point being alarmed) with a pre-defined alarm condition (e.g. a High Limit) and performing some action based on the result of the comparison.

1.3.2 Alarm Handling

see Alarm Routing

1.3.3 Alarm Routing

Alarm routing is M&C software functionality that starts with a notification that an alarm exists (typically as the output of an Alarm Generation process) and sends a specific message to a specific alarm recipient or device.

1.3.4 Application Generic Controller (AGC)(LonWorks)

A device that is furnished with a (limited) pre-established application that also has the capability of being programmed. Further, the ProgramID and XIF file of the device are fixed. The programming capability of an AGC may be less flexible than that of a General Purpose Programmable Controller (GPPC).

1.3.5 Application Specific Controller (ASC)(LonWorks)

A device that is furnished with a pre-established built in application that is configurable but not re-programmable. An ASC has a fixed factory-installed application program (i.e Program ID) with configurable settings.

1.3.6 BACnet (BACnet)

The term BACnet is used in two ways. First meaning the BACnet Protocol Standard - the communication requirements as defined by ASHRAE 135 including all annexes and addenda. The second to refer to the overall technology related to the ASHRAE 135 protocol.

1.3.7 BACnet Advanced Application Controller (B-AAC)(BACnet)

A hardware device BTL Listed as a B-AAC. A control device which contains BIBBs in support of scheduling and alarming but otherwise has limited resources relative to a B-BC. It may be intended for specific applications and supports some degree of programmability.

1.3.8 BACnet Advanced Operator Workstation (B-AWS)(BACnet)

Monitoring and Control (M&C) Software BTL Listed as an Advanced Operator Workstation and includes the ability to manage scheduling, alarming and trending in an open manner. The B-AWS is the advanced operator's window into a BACnet system. It is primarily used to monitor the performance of a system and to modify parameters that affect the operation of a system.

SECTION 25 10 10 Page 7

1.3.9 BACnet Application Specific Controller (B-ASC)(BACnet)

A hardware device BTL Listed as a B-ASC. A controller with limited resources relative to a B-AAC. It is intended for use in a specific application and supports limited programmability.

1.3.10 BACnet Building Controller (B-BC)(BACnet)

A hardware device BTL Listed as a B-BC. A general-purpose, field-programmable device capable of carrying out a variety of building automation and control tasks including control and monitoring via direct digital control (DDC) of specific systems and data storage for trend information, time schedules, and alarm data. Like the other BTL Listed controller types (B-AAC, B-ASC etc.) a B-BC device is required to support the server ("B") side of the ReadProperty and WriteProperty services, but unlike the other controller types it is also required to support the client ("A") side of these services. Communication between controllers requires that one of them support the client side and the other support the server side, so a B-BC is often used when communication between controllers is needed.

1.3.11 BACnet Internetwork (BACnet)

Two or more BACnet networks connected with BACnet routers. In a BACnet Internetwork, there exists only one message path between devices.

1.3.12 BACnet Interoperability Building Blocks (BIBBs) (BACnet)

A BIBB is a collection of one or more BACnet services intended to define a higher level of interoperability. BIBBs are combined to build the BACnet functional requirements for a device in a specification. Some BIBBs define additional requirements (beyond requiring support for specific services) in order to achieve a level of interoperability. For example, the BIBB DS-V-A (Data Sharing-View-A), which would typically be used by an M&C client, not only requires the client to support the ReadProperty Service, but also provides a list of data types (Object / Properties) which the client must be able to interpret and display for the user.

1.3.13 BACnet Operator Display (B-OD)(BACnet)

A hardware device BTL Listed as a B-OD. A basic operator interface with limited capabilities relative to a B-OWS. It is not intended to perform direct digital control. The B-OD profile could be used for wall-mounted LCD devices, displays affixed to BACnet devices; hand-held terminals or other very simple user interfaces.

1.3.14 BACnet Operator Workstation (B-OWS)(BACnet)

Monitoring and Control (M&C) Software BTL Listed as a B-OWS. An operator interface with limited capabilities relative to a B-AWS. The B-OWS is used for monitoring and basic control of a system, but differs from a B-AWS in that it does not support configuration activities, nor does it provide advanced troubleshooting capabilities.

1.3.15 BACnet Smart Actuator (B-SA)(BACnet)

A hardware device BTL Listed as a B-SA. A simple control output device with limited resources; it is intended for specific applications.

SECTION 25 10 10 Page 8

1.3.16 BACnet Smart Sensor (B-SS)(BACnet)

A hardware device BTL Listed as a B-SS. A simple sensing device with very limited resources.

1.3.17 BACnet Testing Laboratories (BTL)(BACnet)

Established by BACnet International to support compliance testing and interoperability testing activities and consists of BTL Manager and the BTL Working Group (BTL-WG). BTL also publishes Implementation Guidelines.

1.3.18 BACnet Testing Laboratories (BTL) Listed (BACnet)

A device that has been certified by BACnet® Testing Laboratory. Devices may be certified to a specific device profile, in which case the certification indicates that the device supports the required capabilities for that profile, or may be certified as "other".

1.3.19 Binary

A two-state system or signal; for example one where an "ON" condition is represented by a high signal level and an "OFF" condition is represented by a low signal level. 'Digital' is sometimes used interchangeably with 'binary'.

1.3.20 Binding (LonWorks)

The act of establishing communications between CEA-709.1-D devices by associating the output of a device to the input of another so that information is automatically (and regularly) sent without being requested by the recipient.

1.3.21 Broadcast

Unlike most messages, which are intended for a specific recipient device, a broadcast message is intended for all devices on the network.

1.3.22 Building Control Network (BCN)

The network used by the Building Control System. Typically the BCN is a BACnet ASHRAE 135 or LonWorks CEA-709.1-D network installed by the building control system contractor.

1.3.23 Building Control System (BCS)

One type of Field Control System. A control system for building electrical and mechanical systems, typically HVAC (including central plants) and lighting. A BCS generally uses Direct Digital Control (DDC) Hardware and generally does NOT include its own local front end.

1.3.24 Building Point of Connection (BPOC)

A FPOC for a Building Control System. (This term is being phased out of use in preference for FPOC but is still used in some specifications and criteria. When it was used, it typically referred to a piece of control hardware. The current FPOC definition typically refers instead to IT hardware)

SECTION 25 10 10 Page 9

1.3.25 Channel (LonWorks)

A portion of the control network consisting of one or more segments connected by repeaters. Channels are separated by routers. The device quantity limitation is dependent on the topology/media and device type.

For example, a TP/FT-10 network with locally powered devices is limited to 128 devices per channel.

1.3.26 Commandable (BACnet)

A point (Object) is commandable if its Present_Value Property is writable and it supports the optional Priority_Array Property. This functionality is useful for Overrides.

1.3.27 Configuration Property (LonWorks)

Controller parameter used by the application which is usually set during installation/testing and seldom changed. For example, the P and I settings of a P-I control loop. Also see 'Standard Configuration Property Type (SCPT)'

1.3.28 Control Logic Diagram

A graphical representation of control logic for multiple processes that make up a system.

1.3.29 Device Object (BACnet)

Every BACnet device requires one Device Object, whose properties represent the network visible properties of that device. Every Device Object requires a unique Object_Identifier number on the BACnet internetwork.

This number is often referred to as the device instance or device ID.

1.3.30 Explicit Messaging (LonWorks)

A non-standard and often vendor (application) specific method of communication between devices.

1.3.31 External Interface File (XIF) (LonWorks)

A file which documents a device's external interface, specifically the number and types of LonMark objects, the number, types, directions, and connection attributes of network variables, and the number of message tags.

1.3.32 Field Point Of Connection (FPOC)

The FPOC is part of the UMCS IP network and acts as the point of connection between the UMCS IP Network and the field control IP network.

The FPOC is an IT device such as a switch, IP router, or firewall, typically managed by the site IT staff. (Note that the field control IP network may consist of a single IP device, or that integration may require installation of a field control network IP device.)

1.3.33 Field Control Network

The network used by a field control system.

SECTION 25 10 10 Page 10

1.3.34 Field Control System (FCS)

A building control system or utility control system.

1.3.35 Fox Protocol (Niagara Framework)

The protocol used for communication between components in the Niagara Framework. By default, Fox uses TCP port 1911

1.3.36 Functional Profile (LonWorks)

A standard description, defined by LonMark International, of a LonMark Object used to classify and certify devices.

1.3.37 Gateway

A device that translates from one protocol to another. Devices that change only the transport mechanism of the protocol - "translating" from LonWorks over TP/FT-10 to LonWorks over IP for example - are not gateways as the underlying protocol (data format) does not change. Gateways are also called Communications Bridges or Protocol Translators.

1.3.38 General Purpose Programmable Controller (GPPC) (LonWorks)

Unlike an ASC or AGC, a GPPC is not furnished with a fixed application program and does not have a fixed ProgramID or XIF file. A GPPC can be (re-)programmed, usually using vendor-supplied software. When a change to the program affects the external interface (and the XIF file) the ProgramID will change.

1.3.39 Internetwork (BACnet)

See BACnet Internetwork.

1.3.40 JACE (Niagara Framework)

Java Application Control Engine. See Niagara Framework Supervisory Gateway

1.3.41 LonMark Object (LonWorks)

A collection of network variables, configuration properties, and associated behavior defined by LonMark International and described by a Functional Profile. It defines how information is exchanged between devices on a network (inputs from and outputs to the network).

1.3.42 LNS Plug-in (LonWorks)

Software which runs in an LNS compatible software tool, typically a network configuration tool. Device configuration plug-ins provide a 'user friendly' method to edit a device's configuration properties.

1.3.43 LonMark (LonWorks)

See LonMark International. Also, a certification issued by LonMark International to CEA-709.1-D devices.

1.3.44 LonMark International (LonWorks)

Standards committee consisting of independent product developers, system

SECTION 25 10 10 Page 11 integrators and end users dedicated to determining and maintaining the interoperability guidelines for LonWorks. Maintains guidelines for the interoperability of CEA-709.1-D devices and issues the LonMark Certification for CEA-709.1-D devices.

1.3.45 LonWorks (LonWorks)

The term used to refer to the overall technology related to the CEA-709.1-D protocol (sometimes called "LonTalk"), including the protocol itself, network management, interoperability guidelines and products.

1.3.46 LonWorks Network Services (LNS) (LonWorks)

A network management and database standard for CEA-709.1-D devices.

1.3.47 LonWorks Network Services (LNS) Database (LonWorks)

The standard database created and used by LonWorks Network Services (LNS) compatible tools, such as LNS Network Configuration tools.

1.3.48 Modbus

A basic protocol for control network communications generally used in utility control systems. The Modbus protocol standard is maintained by The Modbus Organization.

1.3.49 Master-Slave/Token Passing (MS/TP)(BACnet)

Data link protocol as defined by the BACnet standard. Multiple speeds (data rates) are permitted by the BACnet MS/TP standard.

1.3.50 Monitoring and Control (M&C) Software

The UMCS 'front end' software which performs supervisory functions such as alarm handling, scheduling and data logging and provides a user interface for monitoring the system and configuring these functions.

1.3.51 Network (BACnet)

In BACnet, a portion of the control internetwork consisting of one or more segments of the same media connected by repeaters. Networks are separated by routers.

1.3.52 Network Variable (LonWorks)

See 'Standard Network Variable Type (SNVT)'.

1.3.53 Network Configuration Tool (LonWorks)

The software used to configure the control network and set device configuration properties. This software creates and modifies the control network database (LNS Database).

1.3.54 Niagara Framework

A set of hardware and software specifications for building and utility control owned by Tridium Inc. and licensed to multiple vendors. The Framework consists of front end (M&C) software, web based clients, field level control hardware, and engineering tools. While the Niagara

SECTION 25 10 10 Page 12

Framework is not adopted by a recognized standards body and does not use an open licensing model, it is sufficiently well-supported by multiple HVAC vendors to be considered a de-facto Open Standard.

1.3.55 Niagara Framework Supervisory Gateway (Niagara Framework)

DDC Hardware component of the Niagara Framework. A typical Niagara architecture has Niagara specific supervisory gateways at the IP level and other (non-Niagara specific) controllers on field networks (TP/FT-10, MS/TP, etc.) beneath the Niagara supervisory gateways. The Niagara specific controllers function as a gateway between the Niagara framework protocol (Fox) and the field network beneath. These supervisory gateways may also be used as general purpose controllers and also have the capability to provide a web-browser based user interface.

Note that different vendors refer to this component by different names.

The most common name is "JACE"; other names include "EC-BOS", "FX-40", and

"UNC".

1.3.56 Node (LonWorks)

A device that communicates using the CEA-709.1-D protocol and is connected to a CEA-709.1-D network.

1.3.57 Node Address (LonWorks)

The logical address of a node on the network, consisting of a Domain number, Subnet number and Node number. Note that the "Node number" portion of the address is the number assigned to the device during installation and is unique within a subnet. This is not the factory-set unique Node ID (see Node ID).

1.3.58 Node ID (LonWorks)

A unique 48-bit identifier assigned (at the factory) to each CEA-709.1-D device. Sometimes called the Neuron ID.

1.3.59 Object (BACnet)

A BACnet Object. The concept of organizing BACnet information into standard components with various associated Properties. Examples include Analog Input objects and Binary Output objects.

1.3.60 Override

To change the value of a point outside of the normal sequence of operation where this change has priority over the sequence. An override can be accomplished in one of two ways: the point itself may be Commandable and written to with a priority or there may be a separate point on the controller for the express purpose of implementing the override.

Typically this override is from the Utility Monitoring and Control System (UMCS) Monitoring and Control (M&C) Software. Note that this definition is not standard throughout industry.

1.3.61 Point, Calculated

A value within the M&C Software that is not a network point but has been calculated by logic within the software based on the value of network

SECTION 25 10 10 Page 13 points or other calculated points. Calculated points are sometimes called virtual points or internal points.

1.3.62 Point, Network

A value that the M&C Software reads from or writes to a field control network.

1.3.63 Polling

A requested transmission of data between devices, rather than an unrequested transmission such as Change-Of-Value (COV) or Binding where data is automatically transmitted under certain conditions.

1.3.64 Program ID (LonWorks)

An identifier (number) stored in the device (usually EEPROM) that identifies the node manufacturer, functionality of device (application & sequence), transceiver used, and intended device usage.

1.3.65 Property (BACnet)

A BACnet Property - a data element associated with an Object. Different Objects have different Properties, for example an Analog Input Object has a Present_Value Property (which provides the value of the underlying hardware analog input), a High_Limit Property (which contains a high limit for alarming), as well as other properties.

1.3.66 Protocol Implementation Conformance Statement (PICS)(BACnet)

A document, created by the manufacturer of a device, which describes which potions of the BACnet standard are implemented by a given device.

1.3.67 Repeater

A device that connects two control network segments and retransmits all information received on one side onto the other.

1.3.68 Router (LonWorks)

A device that connects two channels and controls traffic between the channels by retransmitting signals received from one subnet onto the other based on the signal destination. Routers are used to subdivide a control network and to control bandwidth usage.

1.3.69 Router (BACnet)

A device that connects two or more BACnet networks and controls traffic between the networks by retransmitting signals received from one network onto another based on the signal destination. Routers are used to subdivide an internetwork and to control bandwidth usage.

1.3.70 Segment

A 'single' section of a control network that contains no repeaters or routers. There is generally a limit on the number of devices on a segment, and this limit is dependent on the topology/media and device type. For example, a TP/FT-10 segment with locally powered devices is limited to 64 devices, and a BACnet MS/TP segment is limited to 32 devices.

SECTION 25 10 10 Page 14

1.3.71 Service (BACnet)

A BACnet Service. A defined method for sending a specific type of data between devices. Services are always defined in a Client-Server manner, with a Client initiating a Service request and a Server Executing the Service. Some examples are ReadProperty (a client requests a data value from a server), WriteProperty (a client writes a data value to a server), and CreateObject (a client requests that a server create a new object within the server device).

1.3.72 Service Pin (LonWorks)

A hardware push-button on a device which causes the device to broadcast a message containing its Node ID and Program ID. This broadcast can also be initiated via software.

1.3.73 Standard BACnet Object/Property/Service (BACnet)

BACnet Objects, Properties, or Services that are standard Objects, Properties, or Services enumerated and defined in ASHRAE 135. Clause 23 of ASHRAE 135 defines methods to extend ASHRAE 135 to non-standard or proprietary information. Standard BACnet Objects/Properties/Services specifically exclude any vendor specific extensions.

1.3.74 Standard Configuration Property Type (SCPT) (LonWorks)

Pronounced 'skip-it'. A standard format type (maintained by LonMark International) for Configuration Properties.

1.3.75 Standard Network Variable Type (SNVT) (LonWorks)

Pronounced 'snivet'. A standard format type (maintained by LonMark International) used to define data information transmitted and received by the individual nodes. The term SNVT is used in two ways. Technically it is the acronym for Standard Network Variable Type, and is sometimes used in this manner. However, it is often used to indicate the network variable itself (i.e. it can mean "a network variable of a standard network variable type"). In general, the intended meaning should be clear from the context.

1.3.76 Subnet (LonWorks)

Consists of a logical grouping of up to 127 nodes, where the logical grouping is defined by node addressing. Each subnet is assigned a number which is unique within the Domain. See also Node Address.

1.3.77 Supervisory Controller

A controller implementing a combination of supervisory logic (global control strategies or optimization strategies), scheduling, alarming, event management, trending, web services or network management. Note this is defined by use; many supervisory controllers have the capability to also directly control equipment.

1.3.78 Supervisory Gateway

A device that is both a supervisory controller and a gateway , such as a Niagara Framework Supervisory Gateway .

SECTION 25 10 10 Page 15

1.3.79 TP/FT-10 (LonWorks)

A Free Topology Twisted Pair network (at 78 kbps) defined by CEA-709.3 .

This is the most common media type for a CEA-709.1-D control network.

1.3.80 TP/XF-1250 (LonWorks)

A high speed (1.25 Mbps) twisted pair, doubly-terminated bus network defined by the LonMark Interoperability Guide lines. This media is typically used only as a backbone media to connect multiple TP/FT-10 networks.

1.3.81 UMCS Network

An IP network connecting multiple field control systems to the Monitoring and Control Software using one or more of: LonWorks ( CEA-709.1-D and CEA-852-C ), BACnet ( ASHRAE 135 Annex J), Modbus or OPC DA.

1.3.82 User-defined Configuration Property Type (UCPT) (LonWorks)

Pronounced 'u-keep-it'. A Configuration Property format type that is defined by the device manufacturer.

1.3.83 User-defined Network Variable Type (UNVT) (LonWorks)

A network variable format defined by the device manufacturer. Note that UNVTs create non-standard communications (other vendor's devices may not correctly interpret it) and may close the system and therefore are not permitted by this specification.

1.3.84 Utility Control System (UCS)

One type of field control system. Used for control of utility systems such as an electrical substation, sanitary sewer lift station, water pump station, etc. Building controls are excluded from a UCS, however it is possible to have a Utility Control System and a Building Control System in the same facility, and for those systems to share components such as the FPOC. A UCS may include its own local front-end.

1.4 SUBMITTALS

Government approval is required for submittals with a "G" designation;

submittals not having a "G" designation are for information only. When used, a designation following the "G" designation identifies the office that will review the submittal for the Government. Submittals with an "S" are for inclusion in the Sustainability Notebook, in conformance to Section 01 33 29 SUSTAINABILITY REPORTING. Submit the following in accordance with Section 01 33 00 SUBMITTAL PROCEDURES and TABLE 1: PROJECT

SEQUENCING:

SD-02 Shop Drawings

UMCS Contractor Design Drawings; G

UMCS Contractor Design Drawings as a single complete package: 3 hard copies and 1 copies on CDROM. Submit hardcopy drawings on ISO A1 34 by 22 inchesorA3 17 by 11 inches sheets, and electronic drawings in both PDF and AutoCAD or Autodesk Revit 2013 format.

SECTION 25 10 10 Page 16

Draft As-Built Drawings; G

Draft As-Built Drawings as a single complete package: 1 hard copies and 1 copies on CDROM. Submit hardcopy drawings must on ISO A1 34 by 22 inchesorA3 17 by 11 inches sheets, and electronic drawings in both PDF and AutoCADAutodesk Revit 2013 format.

Final As-Built Drawings; G

Final As-Built Drawings as a single complete package: 1 hard copies and 1 copies on CDROM. Submit hardcopy drawings on ISO A1 34 by 22 inchesorA3 17 by 11 inches sheets, and electronic drawings in both PDF and AutoCADAutodesk Revit 2013 format.

SD-03 Product Data

Product Data Sheets; G

Computer Software; G

The most recent versions of all computer software provided under this specification delivered as a Technical Data Package. Submit the user manuals for all software delivered for this project with the software.

Enclosure Keys

Certificate of Networthiness Documentation; G

Documentation of existing Certificates of Networthiness or completed Certificate of Networthiness "Application Checklist" via email and on optical disc.

SD-05 Design Data

UMCS IP Network Bandwidth Usage Estimate; G

Four copies of the UMCS IP Network Bandwidth Usage Estimate.

SD-06 Test Reports

Pre-Construction QC Checklist; G

Four copies of the Pre-Construction QC Checklist.

Post-Construction QC Checklist; G

Four copies of the Post-Construction QC Checklist.

Existing Conditions Report; G

Four copies of the Existing Conditions Report.

Start-Up and Start-Up Testing Report; G

Four copies of the Start-Up and Start-Up Testing Report. The Start-Up and Testing report may be submitted as a Technical Data Package.

PVT Phase I Procedures; G

SECTION 25 10 10 Page 17 rickey.johns Highlight

Four copies of the PVT Phase I Procedures. The PVT Procedures may be submitted as a Technical Data Package.

PVT Phase I Report; G

Four copies of the PVT Phase I Report. The PVT Phase I Report may be submitted as a Technical Data Package.

PVT Phase II Report; G

Four copies of the PVT Phase II Report. The PVT Phase II Report may be submitted as a Technical Data Package.

SD-10 Operation and Maintenance Data

Operation and Maintenance (O&M) Instructions; G

Four bound O&M Instructions and 1 copies of the Instructions in PDF format on optical disc. Index and tab bound instructions.

Submit instructions in PDF form as a single PDF file, or as multiple PDF files with a PDF file table of contents containing links to the other files. O&M Instructions may be submitted as a Technical Data Package.

Preventive Maintenance Work Plan; G

Four copies of the Preventive Maintenance Work Plan. The Preventive Maintenance Work Plan may be submitted as a Technical Data Package.

Basic Training Documentation; G

Training manuals for Basic Training delivered for each trainee on the Course Attendance List with two additional copies delivered for archival at the project site. Submit two copies of the Course Attendance List with the archival copies. The Basic Training Documentation may be submitted as a Technical Data Package.

Advanced Training Documentation; G

One set of training manuals delivered for each trainee on the Course Attendance List with two additional copies delivered for archival at the project site. Submit two copies of the Course Attendance List with the archival copies. The Advanced Training Documentation may be submitted as a Technical Data Package.

Refresher Training Documentation; G

One set of training manuals delivered for each trainee on the Course Attendance List with two additional copies delivered for archival at the project site. Submit two copies of the Course Attendance List with the archival copies. The Refresher Training Documentation may be submitted as a Technical Data Package.

SD-11 Closeout Submittals

Closeout QC Checklist; G

SECTION 25 10 10 Page 18 rickey.johns Highlight rickey.johns Highlight rickey.johns Highlight rickey.johns Highlight

Four copies of the Closeout QC Checklist.

1.5 PROJECT SEQUENCING

TABLE I: PROJECT SEQUENCING specifies the sequencing of submittals as specified in paragraph SUBMITTALS (denoted by an 'S' in the 'TYPE' column) and activities as specified in PART 3 EXECUTION (denoted by an 'E' in the 'TYPE' column).

1.5.1 Sequencing for Submittals

The sequencing specified for submittals is the deadline by which the submittal must be initially submitted to the Government. Following submission there will be a Government review period as specified in Section 01 33 00 SUBMITTAL PROCEDURES. If the submittal is not accepted by the Government, revise the submittal and resubmit it to the Government within 14 days of notification that the submittal has been rejected. Upon re-submittal there will be an additional Government review period. If the submittal is not accepted the process repeats until the submittal is accepted by the Government.

1.5.2 Sequencing for Activities

The sequencing specified for activities indicates the earliest the activity may begin.

1.5.3 Abbreviations

In TABLE I the abbreviation AAO is used for 'after approval of' and 'ACO' is used for 'after completion of'.

TABLE I. PROJECT SEQUENCING

ITEM TYPE DESCRIPTION SEQUENCING

(START OF ACTIVITY or

DEADLINE FOR SUBMITTAL)

1 Notice to proceed

2 S Existing Conditions Report 10 days after #1

3 S Design Drawings 30 days after #1

4 S Product Data Sheets and Certificate of Networthiness Documentation

30 days after #1

5 S UMCS IP Network Bandwidth Usage Estimate

30 days after #1

SECTION 25 10 10 Page 19

TABLE I. PROJECT SEQUENCING

ITEM TYPE DESCRIPTION SEQUENCING

(START OF ACTIVITY or

DEADLINE FOR SUBMITTAL)

6 S Pre-construction QC Checklist 30 days after #1

7 E Install UMCS AAO #2 thru #6

8 E Start-Up and Start-Up Testing ACO #7

9 S Post-Construction QC Checklist 10 days ACO #8

10 S Computer Software 10 days ACO #8

11 S Start-Up and Start-Up Testing Report

10 days ACO #8

12 S Draft As-Built Drawings 10 days ACO #8

13 S PVT Phase I Procedures 30 days before scheduled start of #14 and AAO #11

14 E PVT Phase I AAO #13 and #12

15 S PVT Phase I Report 30 days ACO #14

16 S Preventive Maintenance Work Plan AAO #11

17 S O&M Instructions AAO #11

18 S Basic Training Documentation AAO #11 and 10 days before scheduled start of #19

19 E Basic Training (PVT Phase II) AAO #16, #17 and #18

20 S PVT Phase II Report 10 days ACO #19

21 S Final As-Built Drawings 10 days AAO #20

22 S Advanced Training Documentation 10 days before schedule start of #23 and AAO #18

23 E Advanced Training ACO #19, 10 days AAO #22, and no later than 60 days ACO #19

SECTION 25 10 10 Page 20

TABLE I. PROJECT SEQUENCING

ITEM TYPE DESCRIPTION SEQUENCING

(START OF ACTIVITY or

DEADLINE FOR SUBMITTAL)

24 S Refresher Training Documentation 30 days before #25 and AAO #18 and #22

25 E Refresher Training between 10 and 60 days ACO #19 and

AAO #24

26 S Closeout QC Checklist ACO #23

1.6 QUALITY CONTROL (QC) CHECKLISTS

The Contractor's Chief Quality Control (QC) Representative must complete the QC Checklist in APPENDIX A, and must submit the Pre-Construction QC Checklist, Post-Construction QC Checklist and Closeout QC Checklist as specified. The QC Representative must verify each item in the Checklist and initial in the provided area to indicate that the requirement has been met. The QC Representative must sign and date the Checklist prior to submission to the Government.

1.7 OPERATION AND MAINTENANCE (O&M) INSTRUCTIONS

Provide UMCS Operation and Maintenance Instructions which include:

a. Procedures for the UMCS system start-up, operation and shut-down.

b. Final As-Built drawings.

c. Routine maintenance checklist, arranged in a columnar format: The first column listing all installed devices, the second column stating the maintenance activity or stating that no maintenance required, the third column stating the frequency of the maintenance activity, and the fourth column providing any additional comments or reference.

d. Qualified service organization list including points of contact with phone numbers.

e. Start-Up and Start-Up Testing Report.

f. Performance Verification Test (PVT) Procedures and Reports.

PART 2 PRODUCTS

2.1 EQUIPMENT REQUIREMENTS

2.1.1 Product Certifications

For computing devices, as defined in FCC Part 15 , supplied as part of the UMCS provide devices which are certified to comply with the requirements of Class B computing devices.

SECTION 25 10 10 Page 21

2.1.2 Product Sourcing

For units of the same type of equipment, provide products of a single manufacturer. For each major component of equipment provide equipment with the manufacturer's name and the model and serial number in a conspicuous place. For materials and equipment, provide new standard unmodified products of a manufacturer regularly engaged in the manufacturing of such products.

2.1.3 General Requirements

Provide components that meet the following requirements:

a. Portions of the data communications equipment system installed in unconditioned spaces must operate properly in an environment with ambient temperatures between 32 and 120 degrees F and ambient relative humidity between 10 percent and 90 percent noncondensing.

b. Components must accept 100 to 125 volts AC (Vac), 60 Hz, single phase, three wire with a three-pronged, dedicated circuit outlet or be provided with a transformer to meet the component's power requirements.

c. The equipment must meet the requirements of NFPA 70 , UL 60950 , NFPA 262 , FCC EMC, and FCC Part 15 .

2.1.4 Nameplates

Provide nameplates of laminated plastic identifying the function, network address, if applicable, and identifier of the device. Laminated plastic must be at least 0.125 inch thick, white with black center core.

Nameplates must be a minimum of 1 by 3 inch with minimum 0.25 inch high engraved block lettering.

2.1.5 Product Data Sheets

For all products (equipment) specified in PART 2 and supplied under this contract, submit copies of all manufacturer catalog cuts and specification sheets to indicate conformance to product requirements. For M&C Software also include the PICS verifying BTL Listing as a B-AWS.

2.2 CONTROL HARDWARE

2.2.1 Control Protocol Routers

2.2.1.1 LonWorks/IP Router

Provide LonWorks/IP Routers which perform layer 3 routing of CEA-709.1-D packets over an IP network in accordance with CEA-852-C . The router must provide the appropriate connection to the IP network and connections to the CEA-709.3 TP/FT-10 or TP/XF-1250 network. LonWorks/IP Routers must support the Dynamic Host Configuration Protocol (DHCP; IETF RFC 4361 ) for IP configuration and the use of an CEA-852-C Configuration Server (for CEA-852-C configuration), but must not rely on these services for configuration. LonWorks/IP Routers must be capable of manual configuration via a console RS-232 port.

2.2.1.2 BACnet/IP Router

Provide BACnet/IP Routers which perform layer 3 routing of ASHRAE 135

SECTION 25 10 10 Page 22 packets over an IP network in accordance with ASHRAE 135 Annex J and Clause 6. The router must provide the appropriate connection to the IP network and connections to a ASHRAE 135 MS/TP network. Devices used as BACnet/IP Routers must be BTL Listed and must support the Network Management-Router Configuration-B (NM-RC-B) BIBB.

2.2.1.3 Modbus/IP Router

Provide Modbus/IP Routers which perform layer 3 routing of Modbus packets over an IP network in accordance with Modbus. The router must provide the appropriate connection to the IP network and connections to a non-IP Modbus network. Modbus/IP Routers must support the Dynamic Host Configuration Protocol (DHCP; IETF RFC 4361 ) for IP configuration but must not rely on this service for configuration. Modbus/IP Routers must be capable of disabling the capability for remote configuration of Modbus routing information from the IP network.

2.2.2 Monitoring and Control (M&C) Controller Hardware

Provide Monitoring and Control (M&C) Controller Hardware which is a Niagara Framework Supervisory Gateway or a microprocessor-based direct digital control hardware and which communicates over the UMCS IP network using one of:

a. CEA-709.1-D in accordance with CEA-852-C and using only Standard Network Variable Types (SNVTs) as defined by the LonMark SNVT List.

b. ASHRAE 135 in accordance with ASHRAE 135 Annex J and using only Standard ASHRAE 135 services.

Monitoring and Control (M&C) Controller Hardware must either meet the requirements of the LonMark Interoperability Guide or be BTL Listed.

2.2.3 BACnet Supervisory Controller Hardware

Provide BACnet Supervisory Controller Hardware which is direct digital control hardware and which:

a. is BTL Listed

b. communicates using ASHRAE 135 over an IP network in accordance with ASHRAE 135 Annex J

c. has a configurable Object_Name Property

d. supports the following BIBBS

(1) DS-RP-B (Data Sharing–Read Property–B) BIBB for Objects requiring read access from the M&C Software

(2) DS-WP-B (Data Sharing–Write Property–B) BIBB for Objects requiring write access from the M&C Software.

(3) SCHED-E-B (Scheduling-External-B)

(4) AE-N-I-B (Alarm and Event-Notification Internal-B)

(5) AE-ACK-B (Alarm and Event-ACK-B)

SECTION 25 10 10 Page 23

(6) T-VMT-I-B (Trending-Viewing and Modifying Trends-Internal-B)

(7) T-ATR-B (Trending-Automated Trend Retrieval-B)

e. has a Writeable Recipient_List Propery of the Notification Class Object

2.2.4 Control Protocol Gateways

Provide Control Protocol Gateways which perform bi-directional protocol translation between two of the following protocols, or between one of the following protocols and another protocol: CEA-709.1-D , ASHRAE 135, Modbus, Fox protocol, and OPC DA. Provide Control Protocol Gateways which also meet the following requirements.

a. Gateways must have two or more separate network connections, each appropriate for the protocol and media used. A single network connection must not be used for both protocols.

b. Gateways must be capable of being installed, configured and programmed through the use of instructions in the manual supplied by the…