INTEGRATED AUTOMATION SYSTEM SOFTWARE & PROGRAMMING TOOLS

This article is about general and technical requirements for IAS Software & Programming Tools used in Integrated Automation System or Building Automation System.

INTEGRATED AUTOMATION SYSTEM SOFTWARE & PROGRAMMING TOOLS

<THIS SECTION DEFINES THE REQUIREMENTS AND STANDARDS FOR NETWORK MANAGEMENT, APPLICATION PROGRAMMING DEVELOPMENT, POINT CONVENTIONS AND GRAPHICAL USER INTERFACE DEVELOPMENT. THE QUALITY, PRESENTATION AND NAVIGATION OF THE GUI CAN VARY SIGNIFICANTLY. IT IS IMPORTANT TO PROPERLY DEFINE CLIENT EXPECTATIONS FOR THE GUI. IT IS THE DESIGN ENGINEER’S RESPONSIBILITY TO DEFINE THE STANDARDS REQUIRED FOR THE GUI. IF POSSIBLE, THE ENGINEER SHALL PROVIDE SCREEN CAPTURES TO ILLUSTRATE THE INTENT OF THE GUI. THIS IS ESPECIALLY IMPORTANT IF THE EXISTING SYSTEM IS BEING EXPANDED, OR IF THE PROJECT WILL INCORPORATE MULTIPLE FACILITIES SERVICED BY TWO OR MORE SYSTEM INTEGRATORS.

UTILIZE THE GRAPHICS STANDARDS DOCUMENT AS A REFERENCE FOR THE INTENDED PRESENTATION AND OPERATION OF THE SYSTEM. THIS DOCUMENT THROUOUGHLY DEFINES GUI EXPECTATIONS AND CAN BE UTILIZED AS A REFERENCE IN THE DESIGN DOCUMENTATION. REVIEW THE GRAPHICS STANDARDS DOCUMENT WITH THE CLIENT AND OBTAIN THEIR APPROVAL BEFORE INCLUDING IT IN THE DESIGN DOCUMENTS.

THE DETAILS PROVIDED WITHIN THIS SECTION MUST BE VERIFIED AND/OR MODIFIED TO MEET THE REQUIREMENTS OF THE PROJECT. CLOSELY COORDINATE THIS SECTION WITH PROGRAM REQUIREMENTS AND GUI EXPECTATIONS. DO NOT USE ANY OF THE INFORMATION WITHIN THIS SECTION WITHOUT VERIFYING ITS RELEVANCE TO THE PROJECT DESIGN>

GENERAL
- RELATED DOCUMENTS
  - Drawings and general provisions of the Contract, including General and Supplementary Conditions and Division 01 Specification Sections, apply to this Section.
  - Specifications throughout all Divisions of the Project Manual are directly applicable to this Section, and this Section is directly applicable to them.
  - Refer to Section 25 00 00 – Integrated Automation System (IAS) General for definitions and abbreviations.
  - < Graphics Standards Document>
- SUMMARY
  1. This section describes the features and requirements of the hardware and software necessary to manage the Integrated Automation System (IAS) Control Networks. Section Includes: <Modify to Reflect Design Requirements>
    - Network Management
    - Graphical User Interface
    - System Software
    - Application Programming Description
    - Application Control Logic
    - Application Builder
    - Energy Management Applications
    - Graphical User Interface Software
    - User Management
    - Point Structuring
    - Trending
    - Alarm Reporting
    - Dynamic Color Graphics
    - Tree Navigation
    - Parameter change of properties
    - Set point adjustments
    - Execution of global commands
    - Add, delete, and modify graphics and displayed data
    - Scheduling
    - Electrical demand limiting
    - Downloading Memory to field devices
  2. Fully configure systems and furnish and install all software, programming and dynamic color graphics for a complete and fully functioning system as specified.
  3. Provide network management of all IAS control devices.
  4. Provide custom set-up and development of the software to provide the functional and performance requirements specified. Develop system graphics for all specified mechanical and electrical systems, using animated objects to display all system variables and process valves. <It is highly recommended that the design package include either sample screen captures or a graphics standards document to define the presentation, operation and navigation to be provided within the GUI. Utilize the sample screen captures included herein or the Graphics Standards Document as the basis for defining the requirements for the Graphical User Interface.>
  5. Provide supervisory control strategies for mechanical and electrical <and security> systems to permit the global sequence of operations specified herein. <Coordinate with the Design Drawings>
  6. The User Interface software shall provide concurrent support of multiple display nodes utilizing the latest version of <Microsoft Windows 7, 8.1, 10, Server 12 with Mozilla Firefox, Google Chrome or Internet Explorer 10.0 or later> network operating system. The following features as a minimum shall be provided:
  7. Network Operating Software requirements as outlined in Section 25 00 00 (IAS) Integrated Automation System.
  8. <Full RAS and WAN support.>
  9. Provide System Diagnostics to proactively maintain continuous operation of all IAS network devices.
  10. Refer to Section 25 00 00 – Integrated Automation System (IAS) General for general requirements <as well as requirements for interface with Owner’s WAN>.
- REFERENCE STANDARDS
  1. The latest published edition of a reference shall be applicable to this Project unless identified by a specific edition date.
  2. All reference amendments adopted prior to the effective date of this Contract shall be applicable to this Project.
  3. All materials, installation and workmanship shall comply with the applicable requirements and standards addressed within all references.
- LICENSING
  1. Provide or upgrade all licensing for all software packages at all required Niagara N4 JACE Network Controllers, N4 Supervisors, and/or Niagara N4 IP Controllers. IAS licensing shall allow unlimited simultaneous users for access to all aspects of the system including system access, workstations, points, programming, database management, network management, graphics etc. All operator interfaces, programming environment, networking, database management and any other software used by the Contractor to install the system or needed to operate the system to its full capabilities shall be licensed and provided to the Owner. All NCs and N4 Supervisors shall have NICs set for open communication by all vendors as defined in section 25 00 00.
  2. At least two (2) sets of electronic storage media shall be provided with backup software for all software provided, so that the Owner may reinstall any software as necessary. Include all licensing for workstation operating systems, and all required third-party software licenses.
  3. In the last month of the Warranty Period, upgrade all software and firmware packages to the latest release (version) in effect at the end of the Warranty Period.
    1. <1, 3 or 5> Year Software Maintenance license included. Labor to implement not included.
  4. Refer to Section 25 00 00 – Integrated Automation System (IAS) General for further requirements.
Network Management
1. 1. The Contractor shall furnish network management hardware and software to logically manage, configure and program the IAS Control Devices locally. The Contractor shall provide network management of the IAS Control Devices. Network management shall include the following services: Device installation, device configuration, device diagnostics, programming, device maintenance, network variable binding, channel traffic analysis, message priority levels, alarm message routing and repeating and protocol conversion.
  2. Network Management Software shall be an intuitive interface for network design and installation and act as a bridge to integrate <LONWORKS^®, MODBUS and BACnet^®> devices or IP Controllers. The Network Management tool shall include all software modules necessary to provide complete network management, configuration, programming and maintenance locally and via the GUI web browser.
  3. Systems requiring the use of third-party <LONWORKS^®, MODBUS and BACnet^®> network management tools shall not be accepted.
  4. Network management shall include the following services: device identification, device installation, device configuration, device diagnostics, device maintenance and network variable binding.
  5. The Network configuration tool shall also provide diagnostics to identify devices on the network, to reset devices and to view health and status counters within devices.
  6. These tools shall provide the ability to “learn” an existing LonWorks network, regardless of what network management tool(s) were used to install the existing network, so that existing <LONWORKS^®, MODBUS and BACnet^®> devices and newly added devices are part of a single network management database.
  7. The network management database shall be resident in the Network Controller (NC), ensuring that anyone with proper authorization has access to the network management database at all times. Systems employing network management databases that are not resident, at all times and within the control system shall not be accepted.
Graphical User Interface
1. 1. User Interface Software shall be Niagara N4 Supervisor^® development software and shall be configured via the Niagara Framework Workbench N4^® graphical configuration tool using a library of control objects. Provide the following functionality:
    1. The User Interface software shall include support for building automation supervisory control, data acquisition, alarming, historical data collection and trending, and management report generation. The software shall be developed using a Windows based, 32 bit or 64 bit, object oriented programming language. The User Interface software shall have an open architecture design that allows the system to run in a multi-tasking, multi-user environment with support for on-line, dynamic data exchange and the latest version of ODBC with other applications such as spreadsheets, and database programs. The system shall have the built-in flexibility to permit easy configuration of the system in accordance with the specific objectives of the end user, as well as quick and easy modification of the end application by the user in the field.
    2. The GUI shall employ browser-like functionality for ease of navigation. It shall include a tree view (similar to Windows Explorer) for quick viewing of, and access to, the hierarchical structure of the database <refer to screen captures or Graphics Standards Document>. In addition, menu pull-downs, and toolbars shall employ buttons, commands and navigation to permit the operator to perform tasks with a minimum knowledge of the HVAC Control System and basic computing skills. These shall include, but are not limited to, forward/backward buttons, home button, and a context sensitive locator line (similar to a URL line), that displays the location and the selected object identification.
    3. Real-Time Graphic Displays. The GUI shall, at a minimum, provide a completely interactive user interface and shall provide a HTML5 experience and support the following graphical features and functions: <Coordinate with Client Goals and Objectives>
      1. Graphic screens shall be developed using any drawing package capable of generating a GIF, BMP, PDF, or JPG file format. Use of proprietary graphic file formats shall not be acceptable. In addition to, or in lieu of a graphic background, the GUI shall support the use of scanned pictures.
      2. Graphic screens shall have the capability to contain objects for text, real-time values, animation, color spectrum objects, logs, graphs, HTML or XML document links, schedule objects, hyperlinks to other URL’s, and links to other graphic screens.
      3. Modifying common application objects, such as schedules, calendars, and set points shall be accomplished in a graphical manner. Schedule times will be adjusted using a graphical slider, without requiring any keyboard entry from the operator. Holidays shall be set by using a graphical calendar, without requiring any keyboard entry from the operator.
      4. Commands to start and stop binary objects shall be done by right-clicking the selected object and selecting the appropriate command from the pop-up menu. No entry of text shall be required.
      5. Adjustments to analog objects, such as set points, shall be done by right-clicking the selected object and entering the desired value.
    4. System Configuration. At a minimum, the GUI shall permit the operator to perform the following tasks, with proper password access:
      - Create, delete or modify control strategies while the Network Controller is online.
      - Add/delete objects and network variables to the system.
      - Tune control loops through the adjustment of control loop parameters.
      - Enable, disable or create control strategies; configure and program controllers.
      - Generate hard copy records or control strategies on a printer.
      - Select points to be alarm-able and define the alarm state.
      - Select points to be trended over a period of time and initiate the recording of values automatically.
  2. Web Browser Interface Description:
    1. 1. The system shall be capable of supporting an unlimited number of clients using a standard Web browser that will support HTML5 enabled browsers without requiring proprietary operator interface and configuration programs or browser plug-ins (e.g. Mozilla Firefox, Google Chrome or Internet Explorer 10.0 or later). Systems requiring additional software (to enable a standard Web browser) to be resident on the client machine, or manufacture-specific browsers shall not be acceptable.
      2. The Web browser software shall run on any operating system and system configuration that is supported by the Web browser. Systems that require specific machine requirements in terms of processor speed, memory, etc., in order to allow the Web browser to function with the IAS, shall not be acceptable.
        
        Web Browser’s for PC’s: Only the current released browser (Explorer/Firefox/Chrome) will be required as the GUI and a valid connection to the server network. No installation of any custom software shall be required on the operator’s GUI workstation/client. Connection shall be over an intranet or the Internet.
        
        Secure Socket Layers: Communication between the Web Browser GUI and BAS server shall offer encryption using 128-bit encryption technology within Secure Socket Layers (SSL). Communication protocol shall be Hyper-Text Transfer Protocol Secure (HTTPS).
      3. The Web browser shall provide the same view of the system, in terms of graphics, schedules, calendars, logs, etc., and provide the same interface methodology as is provided by the Graphical User Interface. Systems that require different views or that require different means of interacting with objects such as schedules, or logs, shall not be permitted.
      4. The Web browser client shall support at a minimum, the following functions:
        
        User log-on identification and password shall be required. If an unauthorized user attempts access, a blank web page shall be displayed. Security using Java authentication and encryption techniques to prevent unauthorized access shall be implemented.
        
        Graphical screens developed for the GUI shall be the same screens used for the Web browser client. Any animated graphical objects supported by the GUI shall be supported by the Web browser interface.
        
        Storage of the graphical screens shall be in the network web server, without requiring any graphics to be stored on the client machine. Systems that require graphics storage on each client are not acceptable.
        
        Real-time values displayed on a Web page shall update automatically without requiring a manual “refresh” of the Web page.
        
        Users shall have administrator-defined access privileges. Depending on the access privileges assigned, the user shall be able to perform the following:
        
        Modify common application objects, such as schedules, calendars, and set-points in a graphical manner. Schedule times will be adjusted using a graphical slider, without requiring any keyboard entry from the operator. Holidays shall be set by using a graphical calendar, without requiring any keyboard entry from the operator.
        
        Commands to start and stop binary objects shall be done by right-clicking the selected object and selecting the appropriate command from the pop-up menu. No entry of text shall be required.
        
        View logs and charts.
        
        View and acknowledge alarms.
        
        Set up and execute SQL queries on log and archive information.
        
        The system shall provide the capability to specify a user’s (as determined by the log-on user identification) home page. Provide the ability to limit a specific user to just their defined home page. From the home page, links to other views, or pages in the system shall be possible, if allowed by the system administrator.
        
        Graphic screens on the Web Browser client shall support hypertext links to other locations on the Internet or on Intranet sites, by specifying the Uniform Resource Locator (URL) for the desired link.
  3. Alarm console
    1. The system will be provided with a dedicated alarm window or console. This window will notify the operator of an alarm condition, and allow the operator to view details of the alarm and acknowledge the alarm. The use of the Alarm Console can be enabled or disabled by the system administrator.
    2. When the Alarm Console is enabled, a separate alarm notification window will supersede all other windows on the desktop. This window will notify the operator of new alarms and un-acknowledged alarms.
Quality Assurance
1. 1. Utilize commonly available Network Management and Graphical User Interface programs.
  2. The Contractor shall be fully certified in the development and customization of the Niagara N4 software. Software technicians employed for the project shall have a minimum of three previous similar installations encompassing a similar scope of work (i.e., number of control points, custom report development, etc.). Submit resumes of staff proposed to provide Device Configuration system integration services.
  3. Niagara N4 software shall be able to be supported by a minimum of two (2) local maintenance contractors in addition to the Contractor. Local maintenance contractors are defined to be within a <50-mile> radius of the project site and authorized to maintain, customize and diagnose device installations. The following is a list of acceptable providers:
    1. <List Local Niagara N4 Certified Integrators>

PRODUCTS
GENERAL
1. All materials shall meet or exceed all applicable referenced standards, Federal, state and local requirements, and conform to codes and ordinances of authorities having jurisdiction.
SYSTEM SOFTWARE-GENERAL
1. Functionality and Completeness: Contractor shall furnish and install all software and programming necessary to provide a complete and functioning system as specified. Contractor shall include all software and programming not specifically itemized in these Specifications, which is necessary to implement, maintain, operate, and diagnose the system in compliance with these Specifications.
  1. Software Components: All software shall be the most current version. All software components of the BAS system software shall be provided and installed as part of this project. BAS software components shall include:
    - Server Software, Database and Web Browser Graphical User Interface.
    - 1 or 3 or 5 Year Software Maintenance license. Labor to implement not included.
    - Embedded System Configuration Utilities for future modifications to the system and controllers.
    - Embedded Graphical Programming Tools.
    - Embedded Direct Digital Control software.
    - Embedded Application Software.
  2. BAS Server Database: The BAS server software shall utilize a Java Database Connectivity (JDBC) compatible database such as: MS SQL 8.0, Oracle 8i or IBM DB2. BAS systems written to Non -Standard and/or Proprietary databases are NOT acceptable.
2. Configuration: The software shall support the system as a distributed processing network configuration and shall utilize Niagara N4 Supervisor for engineering, installation and commissioning.

Network Management Software
1. General: Utilize Niagara N4 Supervisor
2. Network Management clients shall be capable of performing the following network services by accessing the appropriate network node databases from the Network Services Server:
  1. Device / node installation
  2. Device / node configuration
  3. Device / node diagnostics
  4. Device / node maintenance
  5. Programming
  6. Network variable binding
  7. A network variable browser
  8. A graphical user interface
  9. System diagnostics
3. The Network Management Server Application shall reside on the IAS Local Area Network server. This application shall support multiple thin clients on the Local Area Network via the GUI web browser.
4. Direct Ethernet based driver support for BACnet I/P, OPC (Client), Modbus TCP, LON IP and SNMP.
5. If BACnet is utilized the Supervisor shall be BTL AWS certified.

Protocol Analyzer (For LONWORKS^® Networks only)
1. General: Provide one Protocol Analyzer software package tool, or utilize existing if available, complete with Laptop PC interface card or a physical hardware component with integral software for the purposes of trouble shooting the network.
2. The software package shall include the following three tools for network analysis and monitoring with the listed diagnostics functions:
  1. Protocol Analyzer Tool
    1. Packet Display Contents: Packet number, packet size, time stamp, packet attributes, service type, transaction number, source address, destination address, network variable, message class and message code.
    2. Packet Display Attributes: Priority, alternate path, authentication and idempotent response.
    3. Configurable Display Attributes: Visible packet fields, font name and size and column widths.
    4. Packet Log Options: Log size and fixed size or circular log.
    5. Packet Match Options: Node name, network variable name, message code and transactions.
    6. Packet Type Receive Filter Options: Ack, acked, acked/reminder, challenge, reply, request, request/reminder, response, unacked, unacked repeat and unknown.
    7. Packet Source Node Receive Filter Options: Node name, neuron ID and subnet/node ID.
    8. Packet Destination Node Receive Filter Options: Node name, neuron ID, subnet/node ID, group ID and broadcast address.
    9. Packet Source or Destination Receive Filter Options: Network variable name and message code name.
    10. Detected Error Conditions: CRC error, time-out error, packet too short, packet too long, preamble too short and preamble too long.
  2. Traffic Analysis Tool
    1. Collective Options: Cumulative or snapshot.
    2. Summary Data: Start time, update time, elapsed time, total packets received, average packet size, average packets per second, mN4imum packets per second, bandwidth utilization, packet counts, network error counts, total errors and error rate.
    3. Packet Count Categories: Ack, acked, acked/reminder, challenge, reply, request, request/reminder, response, unacked, unacked repeat and unknown.
    4. Network Error Count Categories: CRC errors, time-out error, packet too long, preamble too short, preamble too long and packets lost.
    5. Data Available via DDE: All summary data.
  3. Network Diagnostics Tool
    1. Commands: Ping, proxy ping, status (test), proxy status, reset, off-line, on-line, wink and clear error log, reset cause and statistics.
    2. Test Data: Software version, most recent error, most recent reset cause and node statistics.
    3. Command Options: Interval or number of operations.
    4. Node Statistics: Transaction errors, transaction time-outs, receive transactions full, lost messages, missed messages, number of packets transmitted at layer 3, number of packets received at layer 3, number of packets received at layer 4, retries, backlog overflow, late acknowledgments and collisions.>

Controller SOFTWARE
1. NETWORK CONTROLLER (NC) Software Residency: Each NC as defined below shall manage communications between the Advanced Unitary Controllers (AUC) and BACnet Touchscreen Communicating Thermostats (BCT) and which are connected to its communications trunks, manage communications between itself and other Network Controllers (NC), Programmable IP Controllers Units (PICU), Programmable Plant Controllers Units (PPCU), Unitary IP Control Units (UICU), and with any Graphical User Interface (GUI) that are part of the IAS, and perform control and operating strategies for the system based on information from any controller connected to the IAS. All software including the following shall reside and execute at the NC:
  1. Real-Time Operating System software
  2. Real-Time Clock/Calendar and network time synchronization
  3. NC diagnostic software including resource management, memory utilization, NC scan times, device counts and device status and logging of NC internal operations
  4. Direct Digital Control software including a library of control objects to perform standard BMS functions as specified in the sequence of operation. (see section 25 90 00)
  5. Energy Management software including a library of objects to perform energy management functions as specified in the sequence of operations. (see section 25 90 00)
  6. The NC shall employ a device count capacity license model that supports expansion capabilities.
  7. The NC shall utilize I/O Expansion Modules (IO-R-16 and/or IO-R-34) for direct control of equipment. (see section 25 90 00)
  8. Remote Communication software utilizing integral software for remote communications including WiFi, Cellular communications and internet technologies
  9. Alarm services software to provide:
    - On call notification services and reporting
    - Programmable Floating alarm limits
    - Emailing of alarms including alarm escalation
    - SMS, line printer, station recipient
    - Alarm acknowledgement via email, SMS and remote alarm portal
    - Alarm history acknowledgement with history and user notations.
    - A minimum of 100 alarm classes
  10. Audit History shall store changes made to objects including time stamp, object name, old value, new value and user identification of the user making the modifications.
  11. Backup service shall be automatically provided to include the entire NC controller. The backup service shall have the ability to exclude specific files in the backed up database.
  12. Email Service shall include the ability to create individual incoming and outgoing email accounts, an email alarm acknowledger, and the ability to specify email recipients.
  13. History Service shall provide access to histories of all activity in the NC. The service shall allow the operator to enable/disable all history collection with a single operation. Tagging of the history files shall allow the user to group and combine histories into a single file.
  14. User and Category Service shall support RSA secureID or LDAP or active directory integrations. The user service shall provide for the capability to create unique users with defined expiration intervals, warning periods and password history length. This service shall provide the ability to define NC object access, navigation to specific objects or graphics, define the user profile. User access shall be capable of being disabled based on time of day.
  15. Weather Service shall provide current weather as well as forecast weather conditions by receiving the current and forecasted weather from any NOAA (National Oceanic and Atmospheric Administration) weather servers. Data obtained from this service may be used for optimization routines as required in the NC.
  16. Web Service shall provide unlimited web access service to the NC. No user seats or licenses shall be required. It shall support HPPT, HTTPs (SSL and/or TLS) Encryption certificates. The service shall allow the user to specify ports other than the default HTTP/HTTPS ports.
  17. Platform Services shall provide the ability to perform:
    - TCP/IP network management
    - License management
    - Serial port configuration and management
    - Certificate management for SSL/ TLS certificates and shall include key store, trust store and lowed ost management. The tool shall provide the ability to create certificates and manage certificates from third parties.
  18. Field device Network management – all communication drivers (BACnet, LonWorks, Modbus etc) shall utilize a single field device network manager tool that provides a common look and feel without regard to protocol.
2. PROGRAMMABLE IP CONTROL UNIT (PICU) Software Residency: Each PICU as defined below shall be capable of control and monitoring of all points physically connected to it. All software including the following shall reside and execute inside the PICU (see Section 25 14 00):
  1. Real-Time Operating System software.
  2. Real-Time Clock/Calendar and network time synchronization.
  3. PICU diagnostic software including resource management, memory utilization and logging of PICU internal operations.
  4. PICU Communication software/firmware.
  5. Direct Digital Control software (see section 25 90 00).
  6. Energy Management software (see section 25 90 00).
  7. The PICU shall employ a device count capacity license model that supports expansion capabilities.
  8. The PICU shall utilize I/O Expansion Modules for direct control of equipment (see section 25 14 00).
  9. Alarm Services, Processing and Buffering software.
  10. Audit History Service shall store changes made to objects including time stamp, object name, old value, new value and user identification of the user making the modification.
  11. Backup Service shall be automatically provided to include the entire PICU controller.
  12. Email Service shall include the ability to create individual incoming and outgoing email accounts, an email alarm acknowledger, and the ability to specify email recipients.
  13. History Services, Data Trending, Reporting, and Buffering software.
  14. Web Services shall provide unlimited web access service to the PICU. No user seats or licenses shall be required. It shall support HPPT, HTTPs (SSL and/or TLS) Encryption certificates. The service shall allow the user to specify ports other than the default HTTP/HTTPS ports.
  15. Platform Services
    1. TCP/IP network management
    2. License management
  16. I/O (physical and virtual) database.
3. PROGRAMMABLE PLANT CONTROL UNIT (PPCU) Software Residency: Each PPCU as defined below shall be capable of control and monitoring of all points physically connected to it. All software including the following shall reside and execute inside the PPCU (see Section 25 14 00):
  1. Real-Time Operating System software.
  2. Real-Time Clock/Calendar and network time synchronization.
  3. PPCU diagnostic software including resource management, memory utilization and logging of PPCU internal operations.
  4. PPCU Communication software/firmware.
  5. Direct Digital Control software (see section 25 90 00).
  6. Energy Management software (see section 25 90 00).
  7. The PPCU shall employ a device count capacity license model that supports expansion capabilities.
  8. The PPCU shall utilize I/O Expansion Modules for direct control of equipment (see section 25 14 00).
  9. Alarm Services, Processing and Buffering software.
  10. Audit History Service shall store changes made to objects including time stamp, object name, old value, new value and user identification of the user making the modification.
  11. Backup Service shall be automatically provided to include the entire PPCU controller.
  12. Email Service shall include the ability to create individual incoming and outgoing email accounts, an email alarm acknowledger, and the ability to specify email recipients.
  13. History Services, Data Trending, Reporting, and Buffering software.
  14. Web Services shall provide unlimited web access service to the PPCU. No user seats or licenses shall be required. It shall support HPPT, HTTPs (SSL and/or TLS) Encryption certificates. The service shall allow the user to specify ports other than the default HTTP/HTTPS ports.
  15. Platform Services shall provide the ability to perform:
    - TCP/IP network management
    - License management
    - Serial port configuration and management
    - Certificate management for SSL/ TLS certificates and shall include key store, trust store and lowed ost management. The tool shall provide the ability to create certificates and manage certificates from third parties.
  16. Field device Network management – all communication drivers (BACnet, LonWorks, Modbus etc) shall utilize a single field device network manager tool that provides a common look and feel without regard to protocol.
  17. I/O (physical and virtual) database.
4. UNITARY IP CONTROL UNIT (UICU) Software Residency: Each UICU as defined below shall be capable of control and monitoring of all points physically connected to it. All software including the following shall reside and execute inside the UICU (see Section 25 14 00):
  1. Real-Time Operating System software
  2. Real-Time Clock/Calendar and network time synchronization
  3. UICU diagnostic software including resource management, memory utilization and logging of UICU internal operations.
  4. UICU Communication software/firmware
  5. Direct Digital Control software (see section 25 90 00).
  6. Energy Management software (see section 25 90 00).
  7. The UICU shall employ a device count capacity license model that supports expansion capabilities.
  8. The UICU shall utilize I/O Expansion Modules for direct control of equipment (see section 25 14 00).
  9. Alarm Processing and Buffering software.
  10. Data Trending, Reporting, and Buffering software.
  11. I/O (physical and virtual) database.
5. ADVANCED UNITARY CONTROLLER (AUC) Software Residency: Each AUC as defined below shall be capable of control and monitoring of all points physically connected to it. As a minimum, software including the following shall reside and execute at the AUC. Other software to support other required functions of the AUC may reside at the NC with the restrictions/exceptions per application provided in Section 25 14 00:
  1. Real-Time Operating System software.
  2. AUC diagnostic software.
  3. AUC Communication software.
  4. Control software applicable to the unit it serves that will support a single mode of operation.
  5. I/O (physical and virtual) database to support one mode of operation.
6. BACNET TOUCHSCREEN COMMUNICATING THERMOSTAT (BCT) Software Residency: Each BCT as defined below shall be capable of control and monitoring of all points physically connected to it. As a minimum, software including the following shall reside and execute at the BCT. Other software to support other required functions of the BCT may reside at the NC with the restrictions/exceptions per application provided in Section 25 14 00:
  - Real-Time Operating System software.
  - BCT diagnostic software.
  - BCT Communication software.
  - Control software applicable to the unit it serves that will support a single mode of operation.
  - I/O (physical and virtual) database to support one mode of operation.
7. Operating System: Controllers shall include a real-time operating system resident in ROM. This software shall execute independently from any other devices in the system. It shall support all specified functions. It shall provide a command prioritization scheme to allow functional override of control functions. Refer also to Section 25 14 00 for other aspects of the controller’s operating system.
8. Network Communications: Each controller shall include software/firmware that supports the networking of controllers on a common communications trunk. Network support shall include the following:
  1. Controller communication software shall include error detection, correction, and re-transmission to ensure data integrity.
  2. Operator/System communication software shall facilitate communications between other NCs, all subordinate AUCs and BCTs, PICUs, PPCUs, UICUs, Gateways and LAN Interface Devices or Operator Workstations. Software shall allow point interrogation, adjustment, addition/deletion, and programming while the controller is on line and functioning without disruption to unaffected points. The software architecture shall allow networked controllers to share selected physical and virtual point information throughout the entire system.
9. Point Database/Summary Table:
  1. All points included in the typical equipment point list must be represented to Owner’s WAN in a common, open protocol format. All points should be provided as <LONMARK standard network variable types, BACnet objects, Modbus registers – Identify the specific format for point definition>.
  2. Network Management: Point/system database creation and modification shall be via a user-friendly, menu-driven program. Network Management software shall support virtual or logic point (points not representing a physical I/O) creation.
10. Diagnostic Software: Controller software shall include diagnostic software that checks memory and communications and reports any malfunctions.
11. Alarm/Messaging Software: Controller software shall support alarm/message processing and buffering software as more fully specified below.
12. Application Programs: Controllers shall support and execute application programs as more fully specified below:
  - All Direct Digital Control software, Energy Management Control software, and functional block application programming software templates shall be provided in a ‘ready-to-use’ state, and shall not require (but shall allow) Owner programming.
  - Line programs shall supply preprogrammed functions to support energy management and functional block application algorithms. All functions shall be provided with printed narratives and/or flow diagrams to document algorithms and how to modify and use them.
13. Security: Controller software shall support multiple level password access restriction.
14. Direct Digital Control: Controller shall support application of Direct Digital Control Logic. All logic modules shall be provided pre-programmed with written documentation to support their application. Provide the following logic modules as a minimum:
  - Proportional-Integral-Derivative (PID) control with analog, PWM and floating output.
  - Two Position control (Hi or Low crossing with deadband).
  - Single-Pole Double-Throw relay.
  - Delay Timer (delay-on-make, delay-on-break, and interval).
  - Hi/Low Selection.
  - Reset or Scaling Module.
  - Logical Operators (And, Or, Not, Xor).
15. <Psychometric Parameters: Controller software shall provide preprogrammed functions to calculated and present psychometric parameters (given temperature and relative humidity) including the following as a minimum: Enthalpy, Wet Bulb Temperature.>
16. Updating/Storing Application Data: Site-specific programming residing in volatile memory shall be uploadable/downloadable from an OWS or CSS connected locally, to the FAC LAN, to the device level network and remotely via the Internet as applicable, but all must be available.
17. Restart: System software shall provide for orderly shutdown upon loss of power and automatic restart upon power restoration. Volatile memory shall be retained; outputs shall go to programmed fail (open, closed, or last) position. Equipment restart shall include a user definable time delay on each piece of equipment to stagger the restart. Loss of power shall be alarmed at operator interface indicating date and time.
18. Time Synchronization: Operators shall be able to set the time and date in any device on the network that supports time-of-day functionality. The operator shall be able to select to set the time and date for an individual device, devices on a single network, or all devices simultaneously. Automatic time synchronization shall be provided.
19. Miscellaneous Calculations: System software shall automate calculation of <psychometric functions>, calendar functions, kWh/kW, and flow determination and totalization from pulsed or analog inputs, curve-fitting, look-up table, input/output scaling, time averaging of inputs and A/D conversion coefficients.

Application PROGRAMMING DESCRIPTION
1. The application software shall be user programmable.
2. This Specification generally requires a programming convention that is logical, easy to learn, use, and diagnose. General approaches to application programming shall be provided by one, or a combination, of the following conventions:
  - Point Definition: Utilize Niagara N4 Supervisor to support input of individual point information.
  - Graphical Block Programming: Manipulation of graphic icon ‘blocks’, each of which represents a subroutine, in a functional/logical manner forming a control logic diagram. Blocks shall allow entry of adjustable settings and parameters via pop-up windows. Provide a utility that shall allow the graphic logic diagrams to be directly compiled into application programs. Logic diagrams shall be viewable either off-line, or on-line with real-time block output values.
  - Functional Application Programming: Pre-programmed application specific programs that allow/require limited customization via ‘fill-in-the-blanks’ edit fields. Typical values would be setpoints gains, associated point names, alarm limits, etc.
  - Line Programming: Textual syntN4-based programming in a language similar to BASIC designed specifically for HVAC control. Subroutines or functions for energy management applications, setpoints, and adjustable parameters shall be customizable, but shall be provided preprogrammed and documented.
3. Provide a means for testing and/or debugging the control programs both off-line and on-line.
4. The controller shall be fully programmable with full functionality on Niagara 4 brand platform.
5. Native function-block programming software and all controller “Setup Wizards” shall be embedded within the Niagara 4 environment.

Application Control Logic
1. The following type of process variable types shall be supported:
  - Discrete: On/Off or 0/1
  - Integer: 32 bit signed integer value between -2,147,483,648 and +2,147,483,647
  - Real: +/- 3.4 E38
  - String: Text string up to 131 characters long
2. System shall have the ability to execute user defined logic scripts. Logic scripts shall be created in an object or statement based programming environment. No compilers or linkers shall be required.
3. System logic shall be able to automatically perform functions such as increase set-points, perform totalization, and check the status of process set-points to take action.
4. System logic shall be able to control and start other application programs running in the multi-tasking environment.
5. System logic shall be able to monitor the status of each process variable in the system, and perform specific functions based on the following parameters:

Normal Status Alarm Status

LoLo Alarm Status Lo Alarm Status

Hi Alarm Status HiHi Alarm Status

Logical Result of Boolean Expression Individual Bit in Word Status (0-31)

Acknowledged Alarm Status Unacknowledged Alarm Status

System shall have the capability to perform application control to turn on/off discrete points, show windows, download recipes, etc. This application logic shall also start and stop other application programs in the multitasking environment, including spreadsheet programs, database programs, and recipe storage programs. Condition Logic shall be able to support up to 32,767 bytes of memory and shall support the following command functions:
- String Functions
- Math Functions
- System Functions
- Add-On Functions
- Miscellaneous Functions
System shall have the capability to perform application control based upon a user definable state of a process variable or the result of an expression involving multiple process variables. This includes discrete variable on or off state, alarm states such as HIHI or LOLO, or equivalence to a specific value.
Each Condition Logic script shall support up to 32,767 bytes of memory.
It shall be possible to define Condition Logic scripts which execute once when the condition expression becomes true, once when the condition expression becomes false or while the condition is true or while the condition is false at a user definable rate down to 55 mSec.
System shall have the ability to execute System Logic when the value of a Process Variable changes.
Data Change Logic shall support up to 32,767 bytes of memory and shall support execution and control of logic.

Application Builder Capabilities

Graphics development tools shall allow the creation of filled rectangles, circles/ellipses, polygons, and arcs. All display elements such as real time and historical trends, alarm summary displays, bitmap images, and charts shall be configurable objects with the capability to be placed in any window in any configuration.
The graphic drawing system shall be object-oriented. The user shall have the capability to arrange graphic objects based on the following commands:
Align Top                                                    Send to FrontAlign Bottom                                               Send to Back
Align Left                                                    Space Horizontal

Align Center Points                                      Rotate Clockwise and Counter Clockwise

Space Vertical                                             Group Objects into a Cell
Graphics Editor shall allow layering of objects to activate specific objects based upon conditions in the process.
Graphics development tools shall allow object placement via a “snap-to-grid” feature with configurable grid spacing.
Graphics development tools shall support an “undo/redo” feature with a configurable number of levels and command display.
The system shall support a library of “self configuring” objects that change properties based on dialog box entries made by the configurator. For example consider a standard setpoint loader object that has a graduated scale and a default range of 0 to 100.0. By simply making entries in a dialog box it shall be possible to change the range of the set-point loader to 32 – 212, change the number of major and minor divisions on the scale, and change the font used for the label text. The object should then redraw itself with new number of tick marks, new spacing, new labels, and new font.
The system shall support the import of .DXF files with the drawing elements imported as native objects. It shall be possible to animate these objects using the full set of object animation properties.
Graphics editor shall also allow the user to import drawings and images in .BMP file format.
In order to ensure the most productive graphics development environment, animated graphic objects or symbols shall be copyable in just two keystrokes, and immediate substitution of a tag name for the duplicated object shall be possible without leaving the graphics editor.
Animated graphic objects or process symbols shall be copyable from one window or display to another with all of their animation characteristics retained, thereby eliminating duplication of effort. In addition, it shall be possible to import windows from another application in this same fashion.
User shall have the capability to add tag name dictionary items while building a display without exiting the graphics editor.
User shall have the capability to search for process tag names while building a display and then get the exact detail of the item (alarm set-points, I/O address, and all other dictionary details) while building a display without exiting the graphics editor.
User shall have online context sensitive help on the display build routines to be able to obtain immediate help should he or she have a question about the details of linking objects to the tag name database dictionary.
The user shall be able to configure graphic screens while the system is monitoring the process.
User shall have the capability to edit tag name items and add new tag names while the system is running the process.
It shall be possible to export the entire database in .CSV format for import and subsequent editing to a spreadsheet such as Excel.
It shall be possible to import the entire database from a .CSV file created with Excel.
A built-in editor shall be provided for the development of logic scripts. The editor shall be a full-featured text editor with single keystroke entry of Tag names, logic constructs and script functions. When a script function is placed in the editing window any arguments necessary for the script function to operate shall be automatically pasted into the window.
Online help shall be provided for all script functions.
The user shall be able to configure and edit logic scripts while the system is monitoring the process.

Report Writer
1. Report Printing Capability
  1. Printed reports shall contain process information including process data, status, accumulated variables, etc.
  2. Reports shall have the capability to include a snapshot of trends, histograms, and SPC charts on the printed report.
  3. Reports shall support use of graphic templates in a printed report.
2. Report Scheduling
  1. Reports shall be able to be scheduled by time of day, day of week, hour of day, or at the end of a shift.
  2. Reports shall be able to be printed on demand by the operator.
  3. Reports shall be able to be printed based on any state change in the system.

ENERGY MANAGEMENT APPLICATIONS
1. System shall have the ability to perform all of the following energy management routines via preprogrammed function blocks or template programs. As a minimum provide the following whether or not required in the software:
  - Meets ANSI C12.20 Accuracy Standard
  - Time-of-Day Scheduling
  - Calendar-Based Scheduling
  - Holiday Scheduling
  - Temporary Schedule Overrides
  - Optimal Start/Optimal Stop-based on space temperature offset, outdoor air temperature, and building heating and cooling capacitance factors as a minimum
  - Night Setback and Morning Recovery Control, with ventilation only during occupancy
  - Economizer Control (enthalpy set-up for heating and cooling)
  - Peak Demand Limiting / Load Shedding
  - Dead Band Control
2. The User Interface HVAC application package shall automatically perform predefined calculations based on operated input, real-time data and required constants. Calculations shall be defined for evaluation by both the User Interface and IAS LAN Clients. Calculations shall include, but not be limited to, the following:
  - Enthalpy: Calculate total heat of air by sensing dry bulb and either relative humidity, wet bulb, or dew point
  - Relative Humidity: Calculate RH from dry bulb temperature and either wet bulb or dew point. Acronym and type of sensor shall be operator input.
  - Wet Bulb: Calculate wet bulb temperature from enthalpy
  - Liquid Flow: Calculate flow rate from differential pressure across an orifice or venturi, or from an annubar sensor. Sensor acronym and type shall be operator input.
  - Zone Heat Energy: Calculate total heat energy in a zone based on dry bulb and either wet bulb, relative humidity, or dew point, and the volume of the space. All parameters shall be operator input.
  - Electrical Power: Calculate electrical power based on voltage and amperage, or on pulse meter input
  - Fluid Btu Rate: Based on flow and differential temperature
  - Addition/Subtraction/Multiplication/Division/ – Min/MN4/Increment/ Decrement: Add, subtract, multiply, divide, selection of min or mN4 for a number of real values and/or constants, and increase or decrease value by a fixed amount to obtain a virtual value.
  - Steam Flow: Calculate steam flow from pressure and temperature values
  - Steam Energy: Btu of steam flow
  - General Degree Three Polynomial.
  - Degree Days
3. Calculated points for which all component data is available within the realm of a single Control Unit shall be downloaded to the Network Controller or IAS LAN Server for calculation. Changes of state shall be reported to the IAS LAN Server as described for analog points. The definition of such a point shall include the creation of a free form algorithm using a command language designed specifically for User Interface applications. In addition to the arithmetic operators listed above, the algorithm shall allow trigonometric, logarithmic, and exponential terms. The time increment of calculating such points shall be on a resolution of 10 seconds.
4. Calculations requiring data from more than one controller shall be defined for evaluation by the User Interface Workstation. The operator shall choose the output units for the calculations from a list. The operator shall be able to determine the time increment for performing calculations on a resolution of 1 minute. Each calculated point shall be assigned a calculation priority which dictates the order in which the calculations are performed. Acronyms of sensed values shall be input by the operator. The operator shall input the value of required constants.
5. Calculated points shall be defined through the operator’s terminal in the same manner as sensed points with additional information requested as required. The calculated point shall appear to the operator as any real point (with a sensor) and the operator shall be able to use the acronym of the calculated point in the same manner as a real point.
6. Run-time Totalizing: Provide the capability to totalize the number of hours that any binary point in the system is in the “on” condition. The point may be a motor, lights, unlocked doors, and so forth. Every binary point shall be able to be totalized on operator assignment.
  - The operator shall be able to set limits associated with run-time. Provide capability to have a limit with every binary point. Limits shall be set through the operator’s keyboard. The system shall print an alarm on the event printer when the run-time of a point reaches the run-time limit. Run-time totals and limits shall be able to be reset from the operator’s terminal on command.
  - The operator shall be able to list a summary of run-time totals and each associated limit, if any. The summary shall be of all binary points or restricted to a particular location, system or point. The summary shall also be able to be restricted to those points that have reached the run-time limit.
7. Analog Totalizing/Averaging: Any analog or calculated point in the system shall be able to be assigned to the totalized and/or averaging program. The points assigned shall be totalized for averaged as minimum of once a minute. The following totals and averages for each point assigned shall be kept in storage.
  - Last 12 Months, by Month
  - Last 30 Days, by Day
  - Last 24 Hours, by Hour
  - Last Hour, by 5 Minute Increments
  - Last 10 Minutes, by Minute
8. Time Based Control
  1. Any commandable point in the system shall be able to be assigned a specific command by time of day and day(s) of week through the operator’s terminal. The number of commands per point, per day, shall be limited only by the amount of memory available in the respective controller. The following commands shall be available:
    - Start
    - Stop
    - Auto
    - Low
    - High
    - Change set-point
    - Change high limit
    - Change low limit
  2. Points shall be assigned time windows in which the assigned command is valid. Points shall be able to be assigned different time windows each day of the week plus a holiday schedule. Provide a means of deleting points from the time schedule by day(s) and time window.
  3. Provide a time delay between starts, within an individual controller, that shall be adjustable on a per point basis.
  4. Time schedules shall be downloaded to the respective controller for implementation. Loss of communication with the User Interface Workstation shall not affect the operation of downloaded time schedules. Any changes made by a time schedule shall be communicated to the User Interface Workstation and saved to the IAS LAN Server.
  5. The operator shall be able to list summaries of time schedules on the operator’s terminal or data logger. The summary shall indicate the point and the various time windows assigned for that particular day. The summary shall be able to be restricted to a particular location, system, system type, point type, or point as well as to those days of the week desired.
  6. Provide a means of scheduling holidays one year in advance. The system shall recognize scheduled holidays and run the holiday schedule for that day or days. The holidays shall be defined through the User Interface Workstation.
  7. Provide a means to extend the time of equipment operation in a particular zone. The extended time shall be initiated from an operator’s keyboard or for a binary input request from the one itself. The extension shall be for a user defined period (minutes, days) and the system shall automatically use the normal schedule the next day. The zone, equipment within the zone (motors, lights, and so forth), and the length of the time extension shall be defined through the User Interface Workstation. Provide a summary of zone parameters and a summary of zones currently operating under extended time.
9. Time and Event Programs
  1. Provide a method for automatically running programs based on occurrence of specified changes in the status of any binary, analog, or calculated point. The following changes in status shall be able to generate an automatic sequence.
    1. Change of binary status from 1 to 0, or 0 to 1
    2. Reaching run-time limit
    3. High analog alarm (adjustable, prioritized)
    4. Low analog alarm (adjustable, prioritized)
    5. Analog return to normal
  2. Each input point in the system shall be able to initiate a program and any number of points shall be able to initiate the same program
  3. Points initiating programs shall pass a number of parameters to the program. These parameters shall be the following:
    1. Acronym of the point
    2. Pointer to the point in the data base
    3. Current status
    4. Last value
  4. Programs shall be assigned to points through the User Interface Workstation. Assignments shall be able to be modified at any time. Time and Event Programs shall be generated at the User Interface Workstation and downloaded to local NC for execution.
  5. The operator shall be able to request a summary of all automatic sequences with point assignments. The summary shall be displayed or printed on the data logger.
10. Duty Cycle
  1. The operator shall be able to assign through the operator’s terminal online any controlled load in the system on the duty cycle program and define associated parameters. Parameters shall be individually assigned per load. Parameters shall be at least as follows:
    1. Acronym of the load start/stop point
    2. Acronym of the point that will feed back, (space temperature, loop temperature, differential pressure, other)
    3. The minimum on and off times for the load required for equipment protection from damage
    4. A description of at least one complete cycle and the time windows in which each is to be followed. At least five different cycles shall be allowed in any one day. The system shall support unique schedules for each day of the week (including holidays) and schedules do not violate the equipment’s minimum on and minimum off times. Cycles shall be defined with a resolution of at least five minutes.
  2. The operator shall be able to modify any parameter on an individual basis at any time
  3. Each load assigned to the duty cycler shall be cycled based on the individual parameters assigned to it. The duty cycler shall not stop the load if the feedback (space temperature, loop temperature, differential pressure, other) is in alarm. In no case shall the load ever be on or off for less time that the minimum on or off times defined.
  4. The operator shall be able to display or print all the parameters associated with a load assigned to the duty cycler on request. Summaries shall be able to be requested for all points or restricted to a particular location or load by operator choice.
  5. Loads shall be able to be locked out from or restored to the duty cycler by the operator at any time
  6. Duty cycling shall be performed by a controller using parameters downloaded from the IAS User Interface Workstation. A change of state shall be reported to the IAS User Interface Workstation Server by the controller each item the duty cycler starts or stops the load.
11. Power Demand Monitoring and Load Shedding
  1. The operator shall be able to assign through the operator’s terminal online any controlled load in the system to the load shed program and define associated parameters. Parameters shall be individually assigned per load. Parameters shall be at least as follows:
    - Acronym of the load start/stop point
    - Acronym of the point that will feed back space conditions or system status to the program (i.e., space temperature, differential pressure, light level (foot-candles), etc.). If no space temperature point exists, this parameter shall not have to be defined.
    - The minimum on and off times for the load required for equipment protection from damage.
    - The kilowatt rating of the load.
    - The acronym of the electric meter that the load is associated with.
    - The priority level of the load. Provided capability of 16 priority levels.
  2. The operator shall be able to modify any load parameter on an individual basis at any time.
  3. The operator shall be able to display or print all of the parameters associated with the load assigned to the load shedding program on request. Summaries shall be able to be requested for all points, or restricted to a particular location or load by operator choice.
  4. Demand meters shall be defined by the operator through the operator’s terminal. Parameters associated with demand meters are as follows:
    - Acronym of the meter
    - The demand limit to begin shedding loads
    - The demand at which loads shall begin to be restored
    - The number of priority level associated with the meter
    - The demand interval strength
  5. The operator shall be able to modify any meter parameters on an individual basis at any time
  6. The operator shall be able to display or print all parameters associated with a particular demand meter on request
  7. The power demand program shall operate on a sliding window basis. Each minute shall be considered to be in the middle of the cycle interval. The demand data shall be gathered each minute. The data from the last N minutes (where N equals one-half the interval length) shall then be used to create a best fit first-degree polynomial curve. The curve shall then be examined at what would be the end of the interval (N minutes ahead). If this value is greater than the shed limit, the power demand program shall calculate the excess load and initiate load shedding. The shedding shall begin with the lowest priority loads and shall be governed by the point’s minimum on time, minimum off time, point disability, and status of the space temperature point (if one has been defined). If the point has not satisfied (continuously) its minimum on time, if the minimum off time has already been reached, if the point is disabled, or if the space temperature point is in alarm, the load initially shall not be shed. If the power demand program finds that it has examined all loads in all priorities and more shedding is still necessary, according to the predicted load, it shall go back to the lowest level and re-examine the points, this time overlooking the status of space temperature points. If it is still unable to adequately reduce the load level, the operator shall be informed of the number of kilowatts still needed to be shed. Under no circumstances shall the system shed a load if the point’s minimum on time has not been satisfied or if the point is disabled.
  8. If at any time after load shedding has been initiated, the system forecasts the end of cycle consumption to be below the restore limit, the power demand program shall begin starting up the loads in order to bring the system back into the state in which it was operating before the shedding began. Load restoration shall be performed in inverse order from that observed in the shedding process. The first group of points to be restored shall consist of those whose sample area is in alarm. The second group shall be the remainder of the power demand monitored points that are currently off and have met their minimum off time. Under no circumstances shall the power demand program restore a point that is either disabled or has not yet satisfied its minimum off time. The starts shall be performed in an efficient manner, each being delayed by the amount of time specified by the preceding point within the same controller. When enough load has been restored so that the forecasted consumption is above the restore limit, the power demand program shall discontinue the restoration process.
  9. Points that are both duty cycled and power demand monitored may be shed by the power demand program, but shall only be started up by the duty cycler. If the duty cycler deems it necessary to start such a point, it shall determine whether the point is off due to load shedding or normal cycling. If the point was shed and an entire power demand program interval has not elapsed since the time of the shed, the duty cycler shall then locate and shed enough other load to allow the original point to be started, without affecting the total system power consumption.
  10. A power demand profile shall be available to the operator upon request. The profile shall be displayed or printed by operator selection. The profile shall include the demand meter description, the time, date, demand limit, restore limit, interval length, current demand, highest demand today and time of occurrence, highest demand yesterday and time of occurrence, highest demand during current billing period with time and date of occurrence, and the highest demand for the last 11 billing periods by billing period with time and date of occurrence, and the highest demand for the last 11 billing periods by billing period with time and date of occurrence. Billing periods shall be able to be defined by the operator through the operator’s terminal.
12. Mixed Air Enthalpy Control
  1. The system shall calculate the enthalpy of the outside air and the return air of each air handling unit assigned to the program. The program shall use the logic required as defined in the sequence of operations.
13. Optimum Start Time
  1. The optimum start program shall calculate the latest start time for air handling units in each operator-defined zone. The calculations shall consider occupancy time, outdoor temperature, indoor temperature, desired indoor temperature at occupancy, the capacity of the air handler(s), and the zone’s heat gain/loss rate.
  2. The program shall run at a reschedule interval of no more than five minutes beginning at an hour that is certain to be before the start-up time for all of the optimum start zones. The program shall examine each zone at the frequency defined for that zone.
  3. When the program determines that the optimum start time has been reached, it shall start all of the air handling units included in the zone definition.
  4. At the zone occupancy time, the system shall record the actual zone temperature and any deviation from desired temperature. If any unit within the zone was found to have been off-line between the startup time and the occupancy time, the data shall be flagged as invalid.
  5. Optimum start zones shall be defined by the operator through the operator’s terminal. Parameters shall include as a minimum:
    1. Occupancy time for each day of the week
    2. Desired temperature at occupancy during heating season
    3. Desired temperature at occupancy during cooling season
    4. Whether the zone is on cooling, heating, or both
    5. Acronym of outdoor temperature sensor
    6. Acronym of indoor temperature sensor
    7. Acronym(s) of air handler(s) to be started
    8. Acronym of the zone
  6. The operator shall be able to modify the parameters at any time. A summary of the zone parameters shall be available on command. The summary shall be displayed on the operator’s terminal or printed on the data logger. This summary shall detail the conditions presented to the optimum start program as well as the results of the optimum start function for one week. The information, output by zone, shall include the difference between the target temperature and both the inside and outside air temperatures at the zone start time, the difference between the target temperature and the actual room temperature at occupancy time, and the start time measured in minutes before occupancy. Performance summaries shall be able to be requested for individual or multiple zones.
14. All programs shall be executed automatically without the need for operator intervention, and shall be flexible enough to allow operator customization.

Graphical User Interface Software

System Protection
1. A supervisory control system is used to control sensitive processes and costly equipment. Therefore, system protection is essential to prevent unauthorized actions on the system or accidental damage to the system. The following describes minimum required system protection capabilities.
2. Foreground Program Switching
  - It shall be possible to configure the run-time system so as to prevent the operator from obtaining direct access to foreground program switching by disabling certain keys in the system. In this way, only the foreground program switching which is built into the end application shall be accessible to the process operator.
3. File Menu Access
  - It shall be possible to configure the run-time system so as to prevent the operator from obtaining direct access to the File Menu or any other direct ability to open and close files outside of the desired built-in capabilities of the final operator interface application.
4. System Level Interface
  - It shall be possible to provide password protection on a moveable mask that can cover the entire system level graphical user interface, including the operating system title bars, menu bars, etc. such that only authorized personnel would have access to this level of control. This protection is necessary to prevent lesser skilled personnel from causing damage to the operator interface application, from accidentally erasing files or records, or from accessing other software not directly connected with the desired plant monitoring and supervisory control application.
5. Operator Log-On
  - It shall be possible to assign each operator a log-on password which defines a unique access level, thereby limiting access to various command functions based on the operator’s access level. Multiple-level password access protection shall be provided to allow the Owner’s authorized IAS Administrator to limit workstation control, display and database manipulation capabilities as IAS Administrator deems appropriate for each user, based upon an assigned user name with a unique password.
  - Based on the operator’s unique password, it shall be possible to log each operator’s actions for later review.
  - It shall be possible to define an inactivity time span between operator actions on the system, requiring the operator to log on again with his password. This capability is useful in preventing unauthorized access to the operator interface system while an operator is away from his station performing other duties.
  - All passwords for the system shall be provided to the Owner including administrator, dealer, or factory level passwords for the systems provided under this Project.
  - Passwords shall restrict access to all Controllers.
  - A minimum of 250 user names shall be supported per Owner’s direction.
Alarm and Event Management Reporting
1. Alarm Display Capability:
  - System shall support displaying of alarms on any display as a user defined sizable object, which may be placed by itself or along with other objects in a window. It shall be possible to scroll forward or backward through the alarm displays by depressing command buttons. Current Alarms shall be available as an Alarm Summary Object and a chronological summary of Alarms shall be available as an Alarm History object.
  - The operator shall be able to select the alarms displayed by an object alarms by group and/or priority by using command buttons. Up to 999 priority levels shall be supported.
  - The system shall support an unlimited number of alarm displays.
  - Alarms shall be color coded according to the state of the alarm, including an acknowledged alarm, unacknowledged alarm, and an alarm that has returned to normal, but is not yet acknowledged. The user shall be able to choose from 32 different colors for display of each of these alarm states. The alarm display object may also support event display with the color used for events also being one of the 32 different colors.
  - The alarm display shall support the display of the following alarm parameters, which are user selectable in the configuration mode:
    - Date                                                                 TimeType of Alarm (HIHI, LOLO, etc.)                        Value of Variable in Alarm
      Operator Name                                                  Alarm Priority
      
      Alarm Group Name                                            Comment
  - It shall be possible to configure the system such that the operator is notified of an alarm no matter what display he or she is currently viewing. Notification shall include the option of a pop-up alarm display window, a flashing process symbol, such as a process vessel, an alarm text message that is available on each display, or a dedicated alarm display window on the screen.
  - The user shall be able to display alarms on an individual or a group basis, with support for sixteen (16) groups, each having up to sixteen (16) subgroups. The alarm hierarchy shall be capable of being nested up to eight (8) levels deep.
  - It shall be possible to inform the operator of an alarm condition via an audible tone, a pop-up display, or any combination of animation types on the screen. Alarm acknowledgment may be performed on all alarms, alarms in a single group, alarms in a collection of groups as defined in an alarm group hierarchy or on a point-by-point basis.
2. Alarm File Capability:
  - Alarms shall be logged to a file for future viewing or review of alarm history data. The user shall have the capability to review the file for cause and event analysis.
  - The alarms that are logged shall be configurable from a choice of the parameters.
3. Alarm Printing Capability:
  - Alarms shall be printed to a printer using either a serial or parallel interface. The format of the alarm printout shall be configurable. All alarms shall be capable of being printed to either a local or a remote network printer.
4. Alarm Transmission Capability:
  1. Alarms shall be transmitted over the Owner’s secure internal wide area network.
  2. Each alarm shall be associated with a priority level and unique user-defined list of operator devices including any combination of local or remote workstations, printers, workstation disk files, e-mail addresses, and pagers. All alarms associated with a given priority level shall be routed to all operator devices on the user-defined list associated with that priority level. For each priority level, alarms shall be automatically routed to a default operator device in the event that alarms are unable to be routed to any operator device assigned to the priority level.
5. Events:
  - Events shall be logged for review by the operator, engineering or management personnel. The system shall log each new operator log-on, and whenever an operator changes a set-point or turns any device on or off. Each time the event log records an event, it will record the operator logged in and the type of action taken (set-point change, state change, etc.), along with a date and time stamp.
Real-Time and Historical Trending
1. The software shall display real-time and historical data in both a tabular and graphical format. The requirements of this trending shall include the following:
  1. Provide trends for all physical points, virtual points and calculated variables.
  2. In the graphical format, the trend shall plot at least four (4) different values for a given time period superimposed on the same graph. The four (4) values shall be distinguishable by using unique colors. In printed form the four (4) lines shall be distinguishable by different line symbology. Displayed trend graphs shall indicate the engineering units for each trended value.
  3. The sample rate and data selection shall be selectable by the operator.
  4. The trended value range shall be selectable by the operator.
  5. Where trended values on one table/graph are COV, software shall automatically fill the trend samples between COV entries.
  6. Real-time trend displays shall support the use of expressions of tag names including add, multiply, divide, etc., to permit proper scaling of variables.
  7. Historical trend display should allow the user to zoom in and out in time from 1 minute up to 6 weeks in one display. It shall be possible to activate the zoom-in and zoom-out features using action scripted command buttons available to the operator.
  8. The operator shall have the capability to pan backward and forward in time to view historically logged data.
  9. Historically collected data shall be available to be exported to a spreadsheet format for analysis, additional reports, etc.
  10. Control Loop Performance Trends: Controllers incorporating PID control loops shall also provide high resolution sampling in less than six second increments for verification of control loop performance.
  11. Data Buffering and Archiving: Trend data shall be buffered at the NC and/or CSS, and uploaded to hard disk storage when archival is desired. All archived trends shall be transmitted to the on-Site OWS or CSS as applicable. Uploads shall occur based upon a user-defined interval, manual command, or automatically when the trend buffers become full.
  12. Time Synchronization: Provide a time master that is installed and configured to synchronize the clocks of all IAS devices supporting time synchronization. All trend sample times shall be able to be synchronized.
Data acquisition and Storage
1. All points included in the typical equipment point list must be represented in a common, open or accessible format. All points should be provided as <LonMark SNVTs, BACnet Objects, Modbus registers – It is important to specify the required format for device and/or system level interoperability. If the format is not specified and enforced the intended level of interoperability may not be achieved>.
2. Data from the IAS shall be stored in a relational database format. The format and the naming convention used for storing the database files shall remain consistent across the database and across time. The relational structure shall allow for storage of any additional data points, which are added to the IAS in future. The metadata/schema or formal descriptions of the tables, columns, domains, and constraints shall be provided for each database.
3. The database shall allow applications to access the data while the database is running. The database shall not require shutting down in order to provide read-write access to the data. Data shall be able to be read from the database without interrupting the continuous storage of trend data being carried by the IAS.
4. The database shall be ODBC or OLE database compliant. Provide a commercially-available ODBC driver or OLE database data provider, which would allow applications to access the data via Microsoft Windows standard data access services.
5. Enterprise level data archiving shall support SQL, MySQL, CSV, Oracle or DB2 database, and HTTP/HTML/XML text formats.
Totalization
- The software shall support totalizing analog, digital, and pulsed inputs and be capable of accumulating, storing, and converting these totals to engineering units used in the documents. These values shall generally be accessible to the Operator Interfaces to support management-reporting functions.
- Totalization of electricity use/demand shall allow application of totals to different rate periods, which shall be user definable.
- When specified to provide electrical or utility Use/Demand, the Contractor shall obtain from the local utility all information required to obtain meter data, including k factors, conversion constants, and the like.
Equipment Scheduling
1. Provide a graphic utility for user-friendly operator interface to adjust equipment-operating schedules.
2. All operators shall be able to view the entries for a schedule. Operators with sufficient privilege shall be able to modify schedule entries from any workstation.
3. Scheduling feature shall include multiple seven-day schedules, plus holiday schedule, each with start time and stop time. Schedules shall be individually editable for each day and holiday.
4. Scheduling feature shall allow for each individual equipment unit to be assigned to one of the schedules.
5. Timed override feature shall allow an operator to temporarily change the state of scheduled equipment. An override command shall be selectable to apply to an individual unit, all units assigned to a given schedule, or to all units in a building. Timed override shall terminate at the end of an operator selectable time. A password level that does not allow assignment of schedules shall allow a timed override feature.
6. A yearly calendar feature shall allow assignment of holidays, and automatic reset of system real time clocks for transitions between daylight savings time and standard time.

Point Structuring and Naming

General:
1. The intent of this Section is to require a consistent means of naming points across the Owner’s WAN. Contractor shall configure the systems from the perspective of the Owner’s WAN, not solely the local Project.
2. The following requirement establishes a standard for naming points and addressing Buildings, Networks, Devices, Instances, and the like.
3. The convention is tailored towards the Owner’s WAN and as such, the interface shall always use this naming convention.
4. <LonMark and BACnet> systems shall use this naming convention. For non-<LonMark and BACnet> systems (e.g. MODBUS), the naming convention shall be implemented as much as practical, and any deviations from this naming convention shall be approved by the Owner.
5. Each Network Controller, Programmable IP Control Unit, Programmable Plant Control Unit, and Unitary IP Control Unit shall have English language descriptors for all system points, variables, parameters etc. located and accessible from the respective NC, PICU, PPCU, or UICU memory. All point naming shall match between all system files and record documents.

Point Summary Table:

The term ‘Point’ is a generic description for the class of object represented by analog and binary inputs, outputs, and values.
With each schematic, Contractor shall provide a Point Summary Table listing:
1. Building code (3 digit building acronym)
2. Floor code
3. Room number
4. Sub room letter
5. Equipment type
6. Equipment number
7. Equipment code
8. Full point name (see Point Naming Convention paragraph)
9. Point description
10. Object type
11. Engineering units
12. Network variable
Additional fields for non-<LonMark and BACnet> systems shall be appended to each row. Point Summary Table shall be provided in both hard copy and in electronic format (ODBC-compliant).
Point Summary Table shall also illustrate Network Variable Data Links.
The IAS Provider shall coordinate with the Owner’s representative to compile and submit a proposed Point Summary Table for review prior to any object programming or Project startup. The Contractor shall support and not impede direct negotiations between the IAS Provider and the Owner to allow the customizing necessary for structuring the IAS point names to meet the Owner’s needs. The Owner shall grant approval of final point names to be verified through Commissioning by issuing the approved alarms to the Contractor.
The Point Summary Table shall be kept current throughout the duration of the Project by the Contractor as the Master List of all points for the Project. Project closeout documents shall include an up-to-date accurate Point Summary Table. The Contractor shall deliver to the Owner the final Point Summary Table prior to final acceptance of the system. The Point Summary Table shall be used as a reference and guide during the Commissioning process.
The Point Summary Table shall contain all data fields on a single row per point. The Point Summary Table is to have a single master source for all point information in the building that is easily sorted and kept up-to-date. Although a relational database of Device ID-to-point information would be more efficient, the single line format is required as a single master table that will reflect all point information for the building. The point description shall be an easily understandable English-language description of the point.

Point Summary Table – Example
(Transpose for a single point per row format)
Building Code	LIB (Library)
Floor Code	04
Room Number	1000
Sub room letter	A
Equipment Type	Air Handler (AH)
Equipment Number	31
Equipment Code	SAT
*Point Name (Object Name)	LIB04_1000a_AH31_SAT
*Point Description (Object Description)	AH31 Supply Air Temperature
Object Type	AI
Engineering Units	Deg f
Network Variable	SNVT_temp
*Represents information that shall reside in the relevant property for the object

Point Naming Convention:

All point names shall adhere to the format as established below. Said objects shall include all physical I/O points, calculated points used for standard reports, and all application program parameters. For each IAS object, a specific and unique name shall be required.
For each point, seven (7) distinct descriptors shall be linked to form each unique object name: Building Code, Floor, Room Number, Equipment Type, Equipment Number or Letter, Equipment Code or Point Description. Each of the four (4) descriptors must be bound by an underscore to form the entire object name. Reference the paragraphs below for an example of these descriptors.
The Owner shall designate the ‘Building’ descriptor. The ‘Equipment Type’ descriptor shall define the equipment category; e.g., Chiller, Air Handling Unit, or other equipment. The ‘Equipment Code’ descriptor shall define the hardware or software type or function associated with the equipment; e.g., supply temperature, water pressure, alarm, mixed air temperature setpoint, etc. and shall contain any numbering conventions for multiples of equipment; e.g., CHLR1KW, CHLR2KW, BLR2AL (Boiler 2 Alarm), HWP1ST (Hot Water Pump 1 Status).
A consistent object (point) naming convention shall be utilized to facilitate familiarity and operational ease across Owner’s WAN. Inter-facility consistency shall be maintained to ensure transparent operability to the greatest degree possible. The table below details the object naming convention and general format of the descriptor string. A maximum of 30 characters shall be used.

Point / Object Name Requirements
Sample: LIB04_1000a_AH31_SAT
(LIB) – Building Code	2 or 3 alpha characters – Building Name
(04) – Floor Location	2 alpha or numeric characters – Must use two characters, such as, (02) for Second Floor
(_)	1 character – underscore; acts as a separator
(1000) – Room Number	3 – 4 numeric characters
(a) – Sub Room Letter	(a-z) if no sub room DO NOT use space or a dash
(_)	1 character – underscore; acts as a separator
(AH) – Equipment Type	2 alpha characters
(31) – Equipment Number, Equipment Letter, or Combination	1-2 upper case alpha and/or numeric characters
(_)	1 character – period; acts as a separator
(SAT) – Equipment Code	1 – 4 alpha characters

Examples: Within each object name, the descriptors shall be bound by an underscore. Within each descriptor, words shall not be separated by dashes, spaces, or other separators as follows:
1. LIB04_1000a_AH31_SAT – Library, 4^th Floor, Rm. 1000a, Air Handler #31, Supply Air Temperature.
2. OFC03_0407_BR01_S/S – Office Building, 3^rd Floor, Rm. 407, Boiler #1, Start/Stop.
3. CH04_0102_VV19_ZSTP – Courthouse, 4^th Floor, Rm. 102, VAV Terminal 19, Zone Temperature Setpoint.

User Input/Control Functions
1. Graphic software shall facilitate user-friendly interface to all aspects of the System Software specified above. The intent of this Specification is to require a graphic package that provides for intuitive operation of the systems without extensive training and experience. It shall facilitate logical and simple system interrogation, modification, configuration, and diagnosis.
2. The operator shall be able to access displays via a pointing device and/or soft key menus with a choice of function keys, cursor control keys, or any key on the keyboard. Supported pointing devices shall include a mouse, touch screen, light pen, or trackball.
3. The system shall support operator access to multiple displays at one time, including split screens where the operator may view more than one process area at a time. In addition, the system shall support unlimited use of pop-up displays for additional help or diagnostic information.
4. Access to all displays and to all command functions shall be based on the operator’s security level to protect against unauthorized use. The security level shall be established during the operator sign-on procedure.
5. Visibility and operation of command buttons, symbols, etc. shall be controllable based upon the operator’s security level.
6. The operator shall be able to have access to context sensitive help at any time during operation of the system.
7. Graphic software shall provide for multitasking such that third-party programs can be used while the OWS software is on line. Software shall provide the ability to alarm graphically even when operator is in another software package.
8. An operator shall be able to control a discrete point using an action command button. This control includes momentary on, momentary off, toggle on-off, set, and reset.
9. The operator shall be able to use command buttons to adjust set-points up and down on a percentage or absolute basis. Each request for increase or decrease shall be evaluated against valid operating limits before allowing the adjustment.
10. Control of individual set-points shall be enabled based upon a user’s security level and password.
Display Capability
1. The software shall allow for Owner creation of user-defined, color graphic displays of geographic maps, building plans, floor plans, and mechanical and electrical system schematics. These graphics shall be capable of displaying all point information from the database including any attributes associated with each point (i.e., engineering units, etc.). In addition, operators shall be able to command equipment or change setpoints from a graphic through the use of the mouse.
2. The system shall allow the user to view animated graphics for process templates including tanks, pumps, etc. This includes:
  1. Percentage fill of the object including irregular shapes such as polygons, ellipses, etc.
  2. Color change of the object. Up to 32 colors.
  3. Blinking of the object based upon any alarm in the system or upon a designated group of alarms.
  4. Each object shall have a visibility attribute option allowing for visibility of the object based upon a condition in the system.
  5. The system shall support animation of objects via resizing, moving, and/or rotating objects based upon a change in a process variable.
  6. Objects shall be animated based upon any user-defined criteria made up of other tag-names in the system. This includes the use of expressions containing all mathematical functions and the status of analog and discrete values in the system.
  7. Objects shall be able to be animated according to any of eight (8) different alarm conditions for an analog variable, including:
  8. Lo Alarm LoLo AlarmHi Alarm HiHi Alarm
    Rate of Change Normal State
3. Objects shall be able to blink or change color by evaluating any of the 32 bits in an analog register. Up to 32 colors shall be possible.
4. The system shall support the capability for the operator to view scanned images from desktop or hand-held scanners. It shall be possible to animate these images to show a color change based on the status of process operations, including alarm or normal state.
5. Screen Penetration: The operator interface shall allow users to access the various system graphic screens via a graphical penetration scheme by using the mouse to select from menus or ‘button’ icons. Each graphic screen shall be capable of having a unique list of other graphic screens that are directly linked through the selection of a menu item or button icon.
6. Dynamic Data Displays: Dynamic physical point values shall automatically updated at a minimum frequency of six (6) updates per minute without operator intervention. Point value fields shall be displayed with a color code depicting normal, abnormal, override and alarm conditions.
7. Point Override Feature: Each displayed point shall be individually enabled/disabled to allow mouse-driven override of digital points or changing of analog points. Such overrides or changes shall occur in the control unit, not just in the workstation software. The graphic point override feature shall be subject to password level protection. Points that are overridden shall be recorded as an event, and shall be displayed in a coded color. The event message shall include the operator’s user name.
8. System shall support use of true-type scalable fonts that may be scaled according to the desired size of the text. The fonts shall be loaded by the operating system. The user may choose from up to 32 different text colors.
9. System shall support change of text color based upon the process value going into eight (8) different alarm states.
10. Text shall be able to blink based upon any user definable condition occurring in the system, such as an alarm on a particular setpoint, alarm on any value in a process group, or based on the actual value of a process variable.
11. System shall display process values based upon the security level of the user.
12. Text shall be able to be made visible or invisible based upon an alarm condition in the process or any other state change in the system.
Graphics Development Package: Graphic development and generation software shall be provided to allow the user to add, modify, or delete system graphic displays.
1. The Contractor shall provide libraries of pre-engineered screens and symbols depicting standard air handling unit components (e.g. fans, cooling coils, filters, dampers, etc.), mechanical system components (e.g., pumps, chillers, cooling towers, boilers, etc.), complete mechanical systems (e.g. constant volume-terminal reheat, VAV, etc.) and electrical symbols.
2. The Graphic Development Package shall use a mouse or similar pointing device to allow the user to perform the following:
  1. Define symbols.
  2. Position items on graphic screens.
  3. Attach physical or virtual points to a graphic.
  4. Define background screens.
  5. Define connecting lines and curves.
  6. Locate, orient and size descriptive text.
  7. Define and display colors for all elements.
  8. Establish correlation between symbols or text and associated system points or other displays.
  9. Create hot spots or link triggers to other graphic displays or other functions in the software.

EXECUTION
SYSTEM CONFIGURATION
1. Contractor shall thoroughly and completely configure IAS system software, supplemental software, network communications, CSS, OWS, remote operator workstations, portable operator’s terminal, printer, and network communications.
2. Contractor shall, after all hardware (devices / nodes and wiring) has been installed, provide all necessary device installation, device configuration, device programming, device diagnostics, network variable binding, alarm management and systems diagnostics. The contractor shall also provide the software tools necessary to perform these services. The software tools shall be registered to the owner.
3. Utilize a protocol analyzer tool to monitor network traffic on all installed DLN control channels for a minimum of 24 hours per channel. Furnish additional hardware and/or reconfigure nodes as necessary to maintain traffic to at least 50% of channel bandwidth capacity or a mN4imum of 70% of the available resources in the Niagara controller.
4. Contractor shall start-up, test, and set all parameters. The Contractor shall demonstrate compliance with all requirements herein. All damaged or malfunctioning software/hardware shall be replaced.
  - Final adjustments shall be performed by specially trained personnel in the direct employment of the Contractor.
  - The Protocol Analyzer shall be utilized to observe, analyze and diagnose the behavior of the installed network.
  - All graphics and alarm monitoring shall be operational and demonstrated before final acceptance.

SITE-SPECIFIC APPLICATION PROGRAMMING
1. Provide all database creation and Site-specific application control programming as required by these Specifications, national and local standards and for a fully functioning system. Provide Site-specific application programming and thoroughly document programming. Meet the intent of the written sequence of operation. It is the Contractor’s responsibility to request clarification on sequence issues.
2. All Site-specific programming shall be fully documented and submitted for review and approval, prior to downloading into the panel, at the completion of functional performance testing, and at the end of the Warranty Period.
3. All programming, graphics and data files must be maintained in a logical system of directories. All file names shall adhere to the naming convention format as established in the Owner’s Standard Acronyms documentation. All software applications, programs, databases and files developed for the Project will be the property of the Owner, will be licensed to the Owner and shall remain on the workstation(s)/server(s) at the completion of the Project.

PASSWORD SETUP
1. Follow <existing> password setup schemes.
POINT PARAMETERS
1. Provide the following minimum programming for each analog input:
  - Name
  - Address
  - Scanning frequency or COV threshold
  - Engineering units
  - Offset calibration and scaling factor for engineering units
  - High and low alarm values and alarm differentials for return to normal condition
  - High and low value reporting limits (reasonableness values), which shall prevent control logic from using shorted or open circuit values
  - Selectable averaging function that shall average the measured value over a user selected number of scans for reporting
2. Provide the following minimum programming for each analog output:
  - Name
  - Address
  - Output updating frequency
  - Engineering units
  - Offset calibration and scaling factor for engineering units
  - Output Range
3. Provide the following minimum programming for each digital input:
  - Name
  - Address
  - Engineering units (on/off, open/closed, freeze/normal, etc.)
  - Debounce time delay
  - Message and alarm reporting as specified
  - Reporting of each change of state, and memory storage of the time of the last change of state
  - Totalization of on-time (for all motorized equipment status points), and accumulated number of off-to-on transitions
4. Provide the following minimum programming for each digital output:
  - Name
  - Address
  - Output updating frequency
  - Engineering units (on/off, open/closed, freeze/normal, etc.)
  - Direct or Reverse action selection
  - Minimum on-time
  - Minimum off-time
  - Status association with a DI and failure alarming (as applicable)
  - Reporting of each change of state, and memory storage of the time of the last change of state
  - Totalization of on-time (for all motorized equipment status points), and accumulated number of off-to-on transitions.

HISTORICAL DATA LOGGING
1. Historical data logging shall be configured and located in the Niagara N4 NC, PICU, PPCU, UICU and archived in the Niagara N4 Supervisor per the owner’s requirements.
2. Archival of the trend logs shall be based on time of day or capacity.
3. Contractor shall establish and store trend logs. Trend logs shall be prepared for each physical input and output point, and all dynamic virtual points such as setpoints subject to a reset schedule, intermediate setpoint values for cascaded control loops, and the like as directed by the Owner.
4. The Owner will analyze trend logs of the system operating parameters to evaluate normal system functionality. Contractor shall establish these trends and ensure they are being stored properly.
  - Data shall include a single row of field headings and the data thereafter shall be contiguous. Each record shall include a date and time field or single date stamp. Recorded parameters for a given piece of equipment or component shall be trended at the same intervals and be presented in a maximum of two separate 2-dimensional formats with time being the row heading and field name being the column heading.
5. Sample times indicated as COV (±) or change-of-value mean that the changed parameter only needs to be recorded after the value changes by the amount listed. When output to the trending file, the latest recorded value shall be listed with any given time increment record. The samples shall be filled with the latest values also if the points include different time intervals.
6. Trending intervals or COV thresholds shall be dictated by the Owner upon system start-up.
7. The Contractor shall demonstrate functional trends as specified for a period of 30 days after successful system demonstration before final acceptance of the system.

TREND Graphs
1. Prepare controller and workstation software to display graphical format trends. Trended values and intervals shall be the same as those specified.
2. Lines shall be labeled and shall be distinguishable from each other by using either different line types, or different line colors.
3. Indicate engineering units of the y-axis values; e.g. degrees F., inches w.g., Btu/lb, percent open, etc.
4. The y-axis scale shall be chosen so that all trended values are in a readable range.
5. Trend outside air temperature, humidity, and enthalpy during each period in which any other points are trended.
6. All points trended for one HVAC subsystem (e.g. air handling unit, chilled water system, etc.) shall be trended during the same trend period.
7. Each graph shall be clearly labeled with variables, date, and times.

ALARMS <Confirm all alarm priorities stated below>
1. This Section supersedes and over rules all references to integrated automation alarms in the Contract Documents, including all sequences of operations and other sections of the IAS Specification in regards to alarms. The Contractor shall support and not impede direct negotiations between the IAS Provider and the Owner to allow the customizing necessary for customizing alarms and alarm parameters to meet the Owner’s needs.
2. The IAS Provider is required to submit a point summary to confirm point names as specified herein The IAS Provider shall submit this point summary with the addition of identifying all alarms which includes detail information on the alarm parameters to the Owner for approval prior to the beginning of any Commissioning process of the integrated automation system.
3. The Owner will provide the format form to the IAS Provider upon request. The Owner shall grant approval of alarms to be verified through Commissioning by issuing the approved alarms to the Contractor. The approved alarms issued to the Contractor shall be used for the Functional Test Procedures alarms tested. The Contractor shall initiate the start of this process immediately after IAS submittal has been approved and monitor the progress to ensure the construction schedule is not delayed.
4. Analog Input Alarms:
  1. Duct Static Pressure:
    1. Alarm @ +(-) 0.3 inches from set point for 5 minutes <@ Priority 3>
    2. Normal @ +(-) 0.2 inches from set point for 5 minutes
    3. Alarm is active after fan is proven ON for the minimum time necessary to allow the sensor to be within the alarm parameter
    4. Alarm is deactivated after fan is proven OFF
  2. Duct Air Temperatures:
    1. Alarm @ +(-) 2.0 degrees F from set point for 5 minutes <@ Priority 3>
    2. Normal @ +(-) 1.0 degrees F from set point for 5 minutes
    3. Alarm is active after fan is proven ON for the minimum time necessary to allow the sensor to be within the alarm parameter
    4. Alarm is deactivated after fan is proven OFF
5. Space or Room Temperature:
  1. <Typically will not be alarm-able>
  2. Submit as not alarm-able and Owner will confirm
  3. Duct or Space Humidity:
    1. Alarm @ (+) 15 percent from set point (60 percent) for 5 minutes <@ Priority 3>
    2. Alarm @ (-) 20 percent from set point (60 percent) for 5 minutes <@ Priority 3>
    3. Normal @ 5 percent from offset alarm parameters for 5 minutes
    4. Point is always ready to alarm.
  4. Water temperature sensors which are inputs to control loops:
    1. Submit reasonable alarm parameter to prevent nuisance alarming <@ Priority 3>.
    2. Owner will confirm alarm.
  5. All other Analog Inputs:
    1. IAS Provider shall utilize their expertise and recommend not less than three (3) analog input alarms which protect the Owner’s best interests.
    2. Submit <@ Priority 3> with recommended alarm parameters.
    3. Identify recommended alarms in submittal.
    4. Owner will confirm alarm.
6. Digital Input Alarms:
  1. Proofs (current sensor, air flow switches, water differential pressure switches etc).
    1. Digital inputs paired with BAS digital output will have the ability to alarm at all times <@ Priority 3>.
    2. Alarm will delay for the reason time needed when the state of the digital output changes to prevent nuisance alarms
    3. Point is in alarmed condition when the value of the digital input does not equal the value of the digital output after the time delay
    4. Point is in the Normal condition when the value of the digital input equals the value of the digital output after the time delay
    5. Digital input proofs without a paired digital output shall not alarm and be for monitoring purposes only.
  2. Safeties (high static cutout, freeze condition, excessive vibration, high humidity cutout, VFD fault, etc.).
    1. The digital input shall be always ready to alarm without delay
    2. The digital input shall display “ALARM” <@ Priority 3> at the Alarm screen when activated.
    3. The digital input shall display “NORMAL” at the Alarm screen when deactivated.
  3. Monitoring Digital Inputs (auxiliary drain pan alarm, Unit general alarm, water detector, etc) the exception is air filter differential pressure switch.
    1. All digital inputs which “deactivated” is the normal state of planned operations shall alarm when the normal state of planned operation changes
    2. The digital input shall display “ALARM” <@ Priority 3> at the Alarm screen when activated
    3. The digital input shall display “NORMAL” at the Alarm screen when deactivated
  4. Air Filters:
    1. <Typically will not be alarm-able.>
    2. Submit as not alarm-able and Owner will confirm.
    3. The digital input shall display “DIRTY” when activated.
    4. The digital input shall display “CLEAN” when deactivated
7. Analog Output Alarms:
  1. All Analog Outputs:
    1. IAS Provider shall utilize their expertise and recommend any analog output alarms which protect the Owner’s best interests.
    2. Identify recommended alarms in submittal.
    3. Owner will confirm any alarms.
8. Digital Output Alarms:
  1. Refer to digital inputs paired with digital outputs as specified herein.
  2. All Digital Outputs:
    - IAS Provider shall utilize their expertise and recommend any digital output alarms which protect the Owner’s best interests.
    - Identify recommended alarms in submittal.
    - Owner will confirm any alarms.
9. Nuisance Alarms: All alarms which have been identified by the Owner as a nuisance alarm due to numerous times in and out of alarm, shall be addressed and corrected by the Contractor in a manner that the Owner has approved.
10. See requirements for additional equipment-specific alarms specified in the Contract Documents.

GRAPHIC SCREENS <define standards for graphic presentation. refer to Niagara N4 graphics standards document>
1. The general look, feel and functionality of the interface <has been established> for all equipment and functions included in the scope of work. The Contractor shall review the <existing> graphic standards in terms of visual appearance and functionality and shall generate a GUI which is in full compliance with the look and functionality defined in the standards. The Owner shall be the final authority for system compliance with this requirement.
2. The Contractor shall use identical graphics, features and logic <from the graphic standards> to replicate new system graphics for the GUI development.
3. <For systems which do not have existing graphics standards the Contractor shall generate new graphics which are similar in nature, look and function to the Niagara N4 Graphics Standards Document>. The Contractor shall submit all new graphics to the Owner for approval prior to replicating for each piece of equipment. Examples of the color graphic dashboard screens shall be provided. Contractor shall provide 3 screen shots from 5 existing projects representing various systems. For each screen, provide a conceptual layout of pictures and data, and show or explain which other screens can be directly accessed
4. The Contractor shall provide graphs, trends, logs and system links for all components as defined in these design documents.
5. The Contractor shall develop the GUI in accordance with all rules and guidelines for development as set by the manufacturer. This shall include following all guidelines for bundles, nested bundles, interstation links, network management, and the rules and guidelines defined by Niagara N4.
6. The Contractor shall coordinate and assist the <Commissioning Authority> with the GUI commissioning process.
7. The Contractor shall develop individual graphics and web pages for the following system components. Actual Design Document AutoCAD or PDF files for risers, floor plans and details shall be incorporated into the GUI development whenever possible. Contact the <Architect, Engineer, Owner> and sign required wavers to gain access to these files.
  1. Provide graphic floor plan screens for each floor of each building.
    - Indicate the location of all equipment that is not located on the equipment room screens.
    - Indicate the location of temperature sensors associated with each temperature-controlled zone (i.e., VAV terminals, fan-coils, single-zone AHUs, etc.) on the floor plan screens.
    - Display the thermo gradient color spectrum of each zone (VAV/AHU) on the floor. The gradient color spectrum shall remain white when the Space Temp is between the active Cooling Setpoint and Heating Setpoint, shall shift to bright red when Space Temp is 4F warmer than active Cooling Setpoint, and shall shift to bright blue when Space Temp is 4F cooler than active Heating Setpoint
    - Include a spectrum legend and any global HVAC floor commands.
    - Display the space temperature point adjacent to each temperature sensor symbol. Use a distinct line symbol to demarcate each terminal unit zone boundary. Use distinct colors to demarcate each air handling unit zone.
    - Mechanical floor plan Drawings will be made available to the Contractor upon request for the purpose of determining zone boundaries. Indicate room numbers as provided by the Owner.
    - Provide a drawing link from each space temperature sensor symbol and equipment symbol shown on the floor plan graphic screens to each corresponding equipment schematic graphic screen.
  2. Provide graphic floor plan screens for each mechanical equipment room. Indicate the location of each item of mechanical equipment. Provide a drawing link from each equipment symbol shown on the graphic plan view screen to each corresponding mechanical system schematic graphic screen.
  3. If multiple floor plans are necessary to show all areas, provide a graphic building key plan. Use elevation views and/or plan views as necessary to graphically indicate the location of all of the larger scale floor plans. Link graphic building key plan to larger scale partial floor plans. Provide links from each larger scale graphic floor plan screen to the building key plan and to each of the other graphic floor plan screens.
  4. Lighting Control Floor Plan
    - Provide Floor Plan graphics divided as needed to clearly indicate the location of each lighting control device.
    - Use <Architect’s AutoCAD> floor plans for this feature.
    - Provide a lighting gradient spectrum floor plan that indicates the current lighting percentage. This shall be a gradient between gray and yellow.
    - Each lighting control device shall incorporate a graphical alarm status light to clearly indicate the location of each device and its current alarm state.
    - Each lighting control device shall be overlaid with a hyperlink to the associated Zone Summary Graphic.
    - The Menu shall allow direct hyperlink to this graphic.
  5. Lighting Control Zone Graphic
    - Provide a graphic for each lighting zone, including the data, overrides and setpoints.
    - Include Room Number(s) and Description for each room or area served by the zone.
    - Incorporate maintenance alarming as available from the lighting control devices, including Lamp / Ballast / Communication Failures if available, for every lighting control device included in the zone.
    - Utilize screen elements (chart buttons, Toolbar, etc) as defined previously in this document. This includes incorporating user access permission levels for Setpoint and Override buttons.
    - The Menu shall allow direct hyperlink to this graphic.
  6. Provide a graphic Site plan with links to and from each building plan.
8. System Schematic Screens: Provide graphic system schematic screen for each <HVAC / CRAC / ATS / Lighting> subsystem controlled with each I/O point in the Project appearing on at least one graphic screen. System graphics shall include flow diagrams with status, setpoints, current analog input and output values, operator commands, etc. as applicable. General layout of the system shall be schematically correct. Input/output devices shall be shown in their schematically correct locations. Include appropriate engineering units for each displayed point value. Verbose names (English language descriptors) shall be included for each point on all graphics; this may be accomplished by the use of a pop-up window accessed by selecting the displayed point with the mouse. Indicate all adjustable setpoints on the applicable system schematic graphic screen or, if space does not allow, on a supplemental linked-setpoint screen.
  1. Provide graphic screens for each <air handling / CRAC system>. Indicate outside air temperature and enthalpy, and mode of operation as applicable (i.e., occupied, unoccupied, warm-up, cool-down). Link screens for air handlers to the heating system and cooling system graphics. Link screens for supply and exhaust systems if they are not combined onto one screen.
  2. Use Toolbar at top of each screen page to provide Equipment information, Server Time/Date, OAT, OARH, Chiller Temp, and to provide hyperlink access to Alarms, Charts, Calendar, and Emergency Stop.
  3. Provide a graphic screen for each zone. Provide links to graphic system schematic screens of air handling units that serve the corresponding zone.
  4. Provide summary graphics for multiple zones for each floor <(e.g. VAV zones)>.
    - <Columns in the Summary shall indicate VAV Name, Space Temp, Setpoint, Occupied Mode, Heat Setpoint, Cool Setpoint, Actual Airflow, MN4 Airflow Setpoint, Cooling Damper Percent, Minimum Airflow Setpoint, and Heating Damper Percent.
    - Rows in the Summary shall indicate the data from a single VAV box
    - Each row shall be overlaid with a hyperlink to the individual VAV Box Graphic
    - Each row shall include a background which will turn red upon any VAV alarm, thus serving as an alarm summary page
    - Each row shall include a background which will turn yellow upon any VAV parameter placed in Override, thus serving as a reminder to return parameters to Automatic
    - The Menu shall allow direct hyperlink to this graphic from “Floors / Floor XX / Area Summary” item>
  5. Link screens for heating and cooling system graphics to utility history reports showing current and monthly electric uses, demands, peak values, and other pertinent values.
  6. Electrical Riser Diagram – <Metering>
    - <Provide an Electrical Riser indicating each panel that is being metered
    - Show power consumption of each panel from this riser graphic
    - Separate building riser into multiple graphics as required
    - Each panel shall be overlaid with hyperlink to meter graphic for that panel
    - Riser shall include data for all panels being monitored
    - The Menu shall allow direct hyperlink to this graphic from “Power” item (or sub-item as required if system is split across multiple graphics)>
  7. <Individual Power Meter Graphic>
    - <Provide detailed metering page for each power meter installed as part of this project. Classify these per floor.
    - Each page shall indicate power meter status, voltage, amperage, power, energy, demand, and power factor for each phase of each meter.
    - Meets ANSI C12.20 Accuracy Standard
    - Each of these components shall be logged, with Chart buttons provided for fast hyperlink to associated log chart.
    - The Menu shall allow direct hyperlink to this graphic.>
  8. Provide graphic animation for the following objects:
    - Damper position
    - Fan status
    - Cooling and Heating Coils
    - Lighting zones
  9. Provide direct links to selected point data/commands for selected variables.
    - <Chart buttons (purple)> shall hyperlink to Trend chart of associated variable.
    - <OR button (yellow)> shall allow access to Overrides, and must incorporate a scheme for managing user permissions. Pop-up menus must use plain English to explain operation.
    - <SP buttons (yellow)> shall allow access to Setpoint adjustment, and must incorporate a scheme for managing user permissions. Pop-up menus must use plain English to explain operation.
9. Alarms: Each programmed alarm shall appear on at least one graphic screen. In general, alarms shall be displayed on the graphic system schematic screen for the system that the alarm is associated with (for example, chiller alarm shall be shown on graphic cooling system schematic screen). For all graphic screens, display analog values that are in a ‘high alarm’ condition in a red color, ‘low alarm’ condition in a yellow co Indicate digital values that are in alarm condition in a red color.

SITE SPECIFIC DEVELOPMENT CRITERIA <define standards for graphic presentation. refer to Niagara N4 graphics standards document>
1. The general look, feel and functionality of the interface <has been established on previous phases> for all equipment and functions <included in previous phase scope of work>. The SI contractor shall review the <existing> system in terms of visual appearance and functionality and shall generate a GUI which is in full compliance with the look and functionality <defined in previous phases>. The SI Contractor shall use identical graphics, features and logic from the existing system to replicate new system graphics.
2. <For systems which do not have existing graphics developed the SI Contractor shall generate new graphics which are similar in nature, look and function to the standards that have been set in previous phases>. The SI contractor shall submit all new graphics to the <Commissioning Agent> for approval prior to replicating for each piece of equipment.
3. The SI Contractor shall provide graphs, trends, logs and system links for all components as defined in these design documents <and as exist on the current functioning system>.
4. The SI Contractor shall develop the GUI in accordance with all rules and guidelines for development as set by Niagara N4. This shall include following all guidelines for bundles, nested bundles, interstation links, network management, and the rules and guidelines defined in Niagara N4 certification program.
5. The SI Contractor shall be responsible for following all rules and guidelines for development as defined by Niagara N4. The <Commission Authority> shall be the final authority for verifying proper programming and development techniques.
6. The SI Contractor shall coordinate and assist the <Commissioning Authority> with the GUI commissioning process.
7. <The governing rule of thumb for GUI development shall be to match existing when the functions, features, or graphics exists>.
8. Not all required graphics are illustrated below however what is shown should be used to judge quality and functionality of all future developments.
9. Existing System Graphics and Performance:
  1. The SI Contractor shall develop individual graphics and web pages for the following system components.
  2. Chart Button Details:
    1. Each Chart Button (purple) shown on the graphics shall be a direct hyperlink to a Niagara N4 Log object. Configure Log Objects with understandable naming convention, configure proper Units for each point, and duplicate Log Size and Interval configuration from similar existing systems.
    2. <INSERT LOG SCREEN CAPTURE HERE>
  3. <Air Handler Graphic>
    - <Each Air Handler shall have a dedicated system graphic.
    - Graphical elements shall reflect actual AHU configuration and installed controls components.
    - When possible, utilize images from Niagara N4’s library.
    - Whenever possible (and as required by other contract documents), provide setpoint adjustments, hardware overrides, log chart hyperlink buttons, hyperlink buttons to associated subsystems or summaries, Toolbar, etc.
    - Utilize common graphical elements and customs specified elsewhere in this document whenever possible.
    - The Menu shall allow direct hyperlink to this graphic from “AHUs / AHU XX” item.>
    - <INSERT AHU SCREEN CAPTURE HERE>
  4. <Computer Room AHU Graphic>

1. 1. - <Each CRAC unit shall have a dedicated system graphic.
    - Display any and all available status and alarm data on graphic as indicated in sample graphic below.

- - - Provide mN4imum setpoint and override access as indicated in sample graphic below.

- - - Utilize existing graphical elements, customs, and standard items from Niagara N4’s library whenever possible.
    - The Menu shall allow direct hyperlink to this graphic from an appropriate location within the tree structure.
    - The HVAC Floorplan or Quadrant graphics shall allow direct hyperlink to this graphic, and shall include temperature spectrum and space temperature information> <similar to each VAV box>.
    - <INSERT CRAC SCREEN CAPTURE HERE>

1. 1. System Home Page

- - - Provide direct links to <AHU, Floor Plan Graphics, VAV summary, Power Meters, and Miscellaneous equipment> graphics from the home page.
    - Icons for each floor or summary or piece of equipment should be tied into the alarms associated with the equipment or floors. This summary home page should indicate when floors or equipment are in alarm.
    - Associate all equipment schedules with the schedule page accessible from this home page.
    - <INSERT HOME PAGE SCREEN CAPTURE HERE>
    - <INSERT SCHEDULE SCREEN CAPTURE HERE>

Discover more from PAKTECHPOINT

Subscribe to get the latest posts to your email.