Vertiv™ Environet
Guide Specifications
Data Center and Facilities Infrastructure Monitoring System
1.0	GENERAL
1.1	SUMMARY
This document contains the specification for a data center and facilities monitoring software solution. The software shall provide real-time (gather data within seconds) monitoring for critical infrastructure at the data center rack, row, room and facility level – including rack power distribution units (rPDU), uninterruptible power supplies (UPS), static transfer switches, branch circuit monitoring systems (BCMS), standby generators, battery monitoring, leak detection systems, fire detection systems, environmental monitoring and other critical equipment capable of communicating as specified.
1.2	system requirements
A.	All material and equipment used shall be standard components, regularly manufactured and available and not custom-designed especially for this project. All systems and components, except site-specific software, shall have been thoroughly tested and proven in actual use prior to installation of this project.
B.	The manufacturer will furnish or supply a site-specific software solution system based on customer requirements.
C.	The system architecture shall be fully modular permitting expansion of application software, peripherals and field hardware.
D.	The solution shall have the option to implement a failover server solution so that functionality is not fully dependent on a single server.
E.	The solution shall be based on open protocols and integrate with Vertiv software suites as well as the Building Management System (BMS).
F.	Open protocols supported shall include, but not be limited to:
•	SNMP v1, 2, 3
•	BACnet MSTP/IP
•	Modbus TCP/RTU via serial or network interfaces
G.	An employee of the manufacturer shall initialize, commission and warrant the solution.
H.	The solution shall have the capability of being remotely monitored and managed 24 hours a day, 7 days a week.
I.	The solution shall have the ability to be deployed with support for monitoring multiple location via a single server.
J.	The solution shall operate as a true Web-based system; the Web interface shall support browsers listed in section 1.4.1, part D and support HTML5.
K.	The solution shall operate on a server provided by the customer, matching the system requirements from the manufacturer; the solution shall support virtual server environments by default.
1.3	approved products
The monitoring system shall be Vertiv Environet as manufactured and commissioned by Vertiv. No substitutions shall be accepted.

1.4	scope of work
1.4.1	Owner-Supplied Items
The owner shall furnish the following system components:
A.	Network (LAN) hardware and software required to provide an Ethernet backbone to be used for transport of IP data packets from critical infrastructure equipment to and from the server and/or gateway hardware. These components may include hubs, routers, cabling, network operating systems, firewalls, IP addresses, Virtual Private Networks (VPN) and other components as required. The owner will supply network drops for the server and gateway hardware (if applicable).
B.	Dedicated server (virtual or standalone) meeting the following requirements:
Requirement	Minimum	Recommended	
Operating System	Windows 7, 8, 8.1, 10
Windows Server 2008 R2
Windows Server 2012 R2
Windows Server 2016	Windows Server 2016	
CPU	(Intel or AMD) 2 CPU 2.0 GHz or Higher	(Intel or AMD) ≥4 CPU ≥2.2 GHz or Higher	
RAM	4 GB	≥16 GB	
Disk Space	100 GB	≥300 GB	
Disk I/O	15 MBps read/write speed	≥200 MBps read/write speed	
Network	10/100 MBps	≥1 GBps	

C.	Server may be virtual environment compatible.
D.	Client access PCs meeting the following minimum requirements:
•	One or more of the following web browsers:
•	Microsoft Edge 
•	Mozilla Firefox  
•	Google Chrome 
E.	The owner shall supply the following information to facilitate system implementation:
•	The customer is responsible for physical installation of all equipment and cabling. The customer is responsible for providing suitable power supplies where required. The customer is responsible for installation of suitable protective earth connection to any item as required by local, state or federal laws.
•	Ensure the server and all other IP devices are in the same network subnet. If they are not in the same network subnet, ensure requests can be routed between the server and networked devices.
•	Provide remote access for programming and administrative rights to install software.
•	Drawings and schematics, as needed, to create graphic pages and configuration.
•	Provide a person as the nominated system owner for administrator purposes.
•	Assistance in defining point descriptions, alarm messages and content for customized graphic pages and configuration.
1.4.2	Vendor Responsibilities
In the overall scope of the project, the manufacturer shall provide one or more of the following components:
A.	Software
•	Server software and license
•	Graphic and software configuration
B.	Control Modules
•	DAC hardware for communication with non-SNMP equipment
C.	Provide hardware and software as listed
•	Create site-specific software configuration and graphic screens based on information provided by the owner or customer.
•	Provide system startup, commissioning and operator orientation by factory-employed system specialist.
•	Provide 24x5 system application and service support through a toll-free number.
•	Provide warranty (parts and labor) per the manufacturer’s warranty statement.
•	The vendor shall be ISO9001 listed for design and manufacture of environmental control systems for Critical Monitoring and Control applications.
1.5	Submittals, Documentation and Acceptance
1.5.1	Submittals
•	Drawings: Floor plan, facility and power one-line drawings shall be approved before any supporting equipment is installed. Drawings must be submitted in time for complete review so that all installations can be completed per the project’s completion schedule.
•	Equipment List: Shall be submitted prior to purchase order and shall consist of a complete list of equipment to be monitored, including manufacturer, model, protocol(s) supported, and any technical literature needed for device communication.
1.5.2	Owner’s Instructions
The vendor shall provide full instructions to designated personnel in the operation, maintenance and programming of the system. The training shall be specifically oriented to the system and interfacing equipment installed.
1.6	general conditions
1.6.1	Warranty
Vertiv shall warrant that all systems, subsystems, component parts and software are fully free from defective design, materials and workmanship for a period of one (1) year from the date of commissioning.
2.0	equipment
2.1	system overview
The vendor shall provide system software based on Web-based architecture, designed around the open standards of Web technology. The server shall be accessed using a Web browser over the owner’s intranet.
At a minimum the software solution shall provide:
•	Unlimited simultaneous users
•	Historical database
•	Built-in alarming, trending and analytics/reporting capabilities
•	Support for third-party integration
•	Open Restful and OBIX API
2.2	web architecture
The intent of the Web architecture is to provide the operator(s) complete access to the system via a Web browser. The graphical user interface (GUI) shall support Microsoft Edge , Google Chrome and Mozilla  Firefox .
2.3	operating system support
The server software must support Microsoft Windows operating environment. (See Section Error! Reference source not found., Item Error! Reference source not found. for minimum system requirements.)
2.4	Graphical User Interface and functionality
A.	The client Web browser GUI shall provide a comprehensive user interface. It shall be constructed to function as an application and provide a complete and intuitive mouse or menu driven interface. It shall be possible to navigate through the system using a Web browser. The Web browser GUI shall (as a minimum) provide a navigation menu for navigation, and a pane for display of graphics, alarms/events, active graphic setpoint controls, configuration menus for operator access, analytics and reporting actions for events. All system graphics are to be HTML 5 compatible.
B.	Supported Browsers: The GUI shall support the following browsers:
•	Microsoft Edge
•	Google Chrome 
•	Mozilla Firefox
C.	Color Graphics: The Web browser GUI shall make extensive use of color in the user interface to communicate status information about the equipment being monitored.
D.	Display Size: The GUI workstation software shall graphically display in 1920 x 1080 pixels and 32-bit true color.
E.	General Graphics: General area maps shall show the locations of controlled buildings in relation to local landmarks, if desired.
F.	Integrated Devices: system graphics shall show the system components via a graphical representation (points, LEDs, labels, gauge(s), and bar charts). Points being controlled or monitored for each piece of equipment shall be displayed with the appropriate engineering units. SNMP devices can be integrated via the web UI by the end user.
•	The equipment view shall show the status of equipment such as rack PDU, UPS, RPP, BCM, cooling, chiller, generator, fire panels and so on. 
•	The view must allow users to drill-down into equipment to view alarms and equipment information in full detail, including individual status of all associated device points. 
G.	Minimum System Color Graphics: Color graphics (32 bit) shall be selected and displayed via a Web browser.
H.	Intuitive Interface: Visualizations of sites are to be customized by the user. The main view will be comprised of the drop-down menu, main view and alarm console. Each of the three can be used for navigation and drill-down into all sites, devices, and other features within the system. 
I.	System Navigation
•	At a minimum, the user must be able to navigate the system through a dropdown menu.
•	The system must provide the capability of using links to navigate through the user interface.
J.	Datacenter Layout Graphics: Layout graphics shall show each piece of equipment monitored or controlled for:
•	Each building
•	Each floor 
•	Each room
•	Each rack 
•	Each individual device
K.	Events and Alarms: Events and alarms associated with a specific system, area or equipment shall be displayed on the main site view and/or within an embedded alarm console. The solution must have native capability to alarm on all connected devices. The alarm system shall have multiple alarm types depending on the severity level. Users must be able to drill down through views to locate alarm sources. The alarm should be accessible from the device level. Events, alarms and reporting actions shall have the following capabilities:
•	Alarm Console: Capable of displaying the following information for each alarm that has occurred in the system: Alarm State (with associated status color), Site, Device, Circuit, Tenant, Point, Point Type, Point Unit, Source, Last Alarm, Acknowledge Requested, Acknowledge State, Last Acknowledgment, Last Acknowledged By, Last Return to Normal, Last Update, Alarm Class, Warning Class, Message and Notes. The Alarm Console must also provide a link to the Site, Device and Point.  
•	User Definitions: Users must be able to choose the thresholds (high and low) for when an alarm and/or warning will activate, along with the points for the severity level. Users must be able to acknowledge and filter alarms. Alarms should have a way to prioritize more important alarms. The solution shall include an alarm history page where all system alarms are stored. Users should be able to search for previous alarms by site, device, or point.
•	Nuisance Alarms: Alarm settings should also contain time delay and deadband settings to help reduce the amount of nuisance alarms that occur within the data center.
L.	Alarm / Event Notification: The solution must be able to notify different users based on the type of alarm. Users should be able to acknowledge alarms remotely. The alarm system should be able to notify users until a person acknowledges the alarm via escalating alarm levels. The alarm system should be able to alert users via email. The solution must allow users to customize alarm messages by escalation level. Unique alarm instructions must be available within the system. Users must be able to edit messaging for alarms and return to normal statuses. The user shall be able to:
•	View events throughout the system.
•	Dependent on access level, manage the event through acknowledgements, deletions, sorting rules and viewing alarm notes.
•	Configure Alarm / Event notifications:
•	Alarm console and alarm pop up window
•	E-mail
M.	Configuration of operators
•	User names and passwords:
•	Permissions: The Permissions field allows administrators to set access level for different users. Permissions include the following options:
(a)	Read/Write: Full read access and full write access to the entire system.
(b)	Read Only: Full read access but no writes or changes may be done.
(c)	Read/Ack: Full read but no write or changes may be done, except to alarm database for acknowledging alarms. System owner shall have the ability to assign combinations of roles and privileges to users that define access levels.
N.	Audit History: A log shall record operator activities and some system activities, such as opening and closing the database or automatic deletions.
O.	Histories/Trending: Histories shall be user-configurable and displayed via the GUI. Trends shall comprise of native points, along with calculated points (collections of point data). A trend log’s properties shall be editable within the GUI.
•	Viewing Trends: The operator shall have the ability to view trends with a time series line chart by using the history database or by selecting a trends button (triangle) in the GUI. The line chart must be exportable within the pop-up window to XLS and able to be saved to a report within the Analytics tool.
•	Historical Data Records: Trend data shall be collected locally and retained within the local hard drive.
•	History Intervals: Historical records shall be saved to match the user defined polling interval. Each trended point shall have the ability to be trended at a unique interval as specified by the user.
•	Tolerance: The user shall be able to enter a value for tolerance (change of value) – if point data changes by the specified amount in between historical reading, a separate record will be created. 
•	Numeric Value Display: It shall be possible to mouse over any value on a history chart and have the numerical value and time of data capture displayed.
•	Systemwide Trends: Any trend point in the system can be evaluated alongside any other trend point in the system. Unit or location shall not define trends.
•	Graph Appearance: Trend values can be presented in line chart graphical format. 
P.	Global Parameter Change: The system shall have the ability to execute a global parameter change (for example, bulk config of all points or a filtered subset of points for historical trending and/or alarm setpoints).
Q.	Analytics and Reports: The software solution shall allow users to view previously created reports as well as to create new, user-defined reports, using drag-and-drop functionality. 
•	Reports shall contain Reportlets (visualizations) utilizing the following graphic types:
•	Simple Value
•	Gauge
•	Table
•	Time Series
•	Scatter Plot
•	Pie Chart
•	User Text
•	User Image
•	User defined reports shall include, but not be limited to:
•	Alarms
•	Historical device data
•	Trend data based on user-defined timeframe
•	Each report can be run ad-hoc within the Analytics feature.
•	Each report shall have the ability to be saved electronically. Standard and user-defined reports can be saved in the following file formats:
•	XLS
•	PDF
•	Each report shall have the ability to be delivered via email, using a daily/weekly/monthly schedule.
R.	IT Racks: The DCIM solution provides IT rack management tools and contain the following capabilities:
•	IT rack view where the user can search IT racks by name, make, model, serial number, asset tag and so on.
•	The user should be able to associate power and environmental data to each rack.
•	Other important rack information such as rack location, RU used, RU free, contact details, etcetera – along with the ability to select/deselect columns from the view. 
•	The user must also be able to create custom columns for inputting custom data. 
•	Allow users to add new racks to the system and export/import rack data using spreadsheet format, to include install IT assets within the rack. 
•	The user must be able to link to the individual rack view from the main rack database.
S.	IT Assets: The DCIM solution must provide asset management tools with the following capabilities: 
•	The DCIM shall contain an asset view where the user can search various IT assets by name, model, serial number, or rack. 
•	Include other important asset information such as install date, warranty expiration dates, rack location and positioning, etc. 
•	The user must also be able to create custom columns for inputting custom data. 
•	Allow users to add new asset to the system and export/import asset data using spreadsheet format.
T.	Tenants: The DCIM solution must contain a system for managing tenants. The tenant management feature Has the following capabilities:
•	Ability to assign tenants to power circuits.
•	Display power usage statistics per tenant.
•	Provide reports for live and historical tenant data, scheduled and available for immediate download to spreadsheet and/or PDF.
•	Include the possibility of adding tenant portals, abbreviated versions of the DCIM solution which provides power and space usage details to tenants. 
•	Be accessible via a web browser and require per tenant login credentials.
U.	Maintenance: The DCIM solution must provide users with a feature to manage device maintenance events. The maintenance feature will silence all alarms and trending on specific equipment or multiple pieces of equipment for the duration of the event. 
•	Users must be able to place a device into maintenance mode instantly or schedule maintenance within the interface, for single or multiple devices at a time.
•	Users have the option to receive notification for the start and end of maintenance events.
•	Maintenance events must include start and end dates, devices, and task descriptions. 
•	Users must be able to view maintenance history. 
•	The solution shall allow users to add, edit, and delete maintenance tasks. Events that have completed cannot be deleted.
2.5	SOFTWARE INTEGRATION
The software solution shall support software integration via its open API.
2.6	SECURITY
The software solution shall also be subject to owner’s policies for security without effect on the Server or Client operation.
•	The system shall not deploy protocols inherently susceptible to intrusion.
•	The system shall strip all unnecessary files and services from the Web service to protect the owner from intrusions.
2.7	DATABASE SUPPORT
The software solution shall support the following databases as a minimum:
•	Niagara
•	MySQL
2.8	SOFTWARE COMPONENTS
All components of the software solution shall be installed and completed in accordance with the specification. Components shall include:
•	Server software, database and Web browser Graphical User Interface
•	System configuration utilities for future modifications to the system
2.9	HARDWARE MODULES
Hardware modules shall use Fox or the Niagara Network as the native communication protocol between controller and server and be capable of communicating with infrastructure via standard protocols.
2.9.1	General Specification
Control modules convert communication protocols, so data can be sent directly to Environet from various critical equipment. 
A.	Protocols: BACnet over IP, BACnet MS/TP, BACnet IP Server, Modbus RTU, Modbus RTU Slave, Modbus TCP, Modbus TCP Slave, SNMP
B.	Hardware Specifications: TI AM3352 1000MHZ ARM Cortex A8 processor, 1GB DDR3 SDRAM, removable micro-SD card with 4GB flash total storage, 2GB user storage (station)
C.	Power: Connection to a UPS battery backup system, graceful shut down if not on UPS, 24VAC/DC power supply terminal, Optional 24VDC universal wall adapter
D.	Ports: (2) 10/100MB Ethernet, (2) Isolated RS-485 with selectable bias and termination, USB Type A for backup and restore support, Wi-Fi is disabled
E.	Environmental Specifications: Operating Temperature: -20 to 60C, storage temperature: -40 to 85C
F.	Humidity: 5-95%, Non-condensing
3.0	Execution
3.1	general
The vendor, unless specified in other sections of the specifications, shall install all equipment and devices furnished under this section of these specifications. The vendor shall install all other equipment, appurtenances, devices and auxiliaries thereto that are required to make the system complete and operative.
Terminate hardware module wiring required to complete the installation.