IT Guide for Novar Opus

Transcription

1 IT Guide for Novar Opus Opus is a suite of hardware and software components that combine to provide a comprehensive enterprise building automation system (BAS). An Opus BAS provides coordinated control and management of building equipment operation across an enterprise with geographically dispersed buildings, and provides corporate facility and energy management staff with equipment status and performance information that can be used to manage energy usage and maintenance activities across the enterprise. This guide is intended for IT professionals tasked with providing and supporting the infrastructure necessary for an Opus enterprise building automation system (BAS) deployment. Opus technology and functionality is explained with emphasis on IT integration capabilities and deployment scenarios. System requirements and resource usage information is also provided for use in hardware and software selection. 8 Table of Contents Opus Under the Hood: The NiagaraAX Framework... 2 Opus BAS Component Descriptions Opus Architecture Diagrams Opus Communication and Networking... 9 System Requirements Data Security User Management Network Traffic and Bandwidth Utilization History and Alarm Database Growth and Capacity Planning Remote Network Connectivity Rev. 1.0 Date 7/31/2017 1

2 Opus Under the Hood: The NiagaraAX Framework Opus is built on Tridium s NiagaraAX framework, which is a software platform that provides developers which a rich set of tools and utilities that can be used to create a wide range of building automation system applications. The design intent of this software is to provide a framework that can be used to integrate diverse devices and systems into a common data model, and to provide a development environment that can be used to create building automation applications. Central to the NiagaraAX framework is the use of the Java virtual machine (JVM), which acts as a common runtime environment that runs all NiagaraAX programs and processes. The term host is used to describe the computing platform that the NiagaraAX framework is running on the host can be a workstation or a server, or an embedded controller; all NiagaraAX hosts require the Java runtime environment (JRE). A brief description of the NiagaraAX framework s four basic programs and processes is presented here as a precursor to descriptions of Opus BAS components and architecture that follow later in this guide; Opus technology fully incorporates and builds on all of these programs and processes: Station: The station is a Java Virtual Machine (JVM) that runs the Niagara AX application software that Opus is built on a station runs the building automation system applications on a host, which includes various components and services. A station also runs on an embedded processor in a BMS controller. Workbench: Workbench is an engineering toolset used to develop and configure building automation applications. Workbench also provides a number of drivers that can be used to establish device interconnectivity across a number of different protocols. Daemon: This is a Java daemon that runs the platform in a NiagaraAX host; the platform equates to the operating system, providing the background tools required for setup, support and troubleshooting. The platform provides a toolset used for all of the following functions on a host: Performing station installations and backups Starting and stopping, and monitoring the station Configuring TCP/IP settings Performing operating system installations and upgrades on embedded hosts Installation and upgrade of the Java virtual Machine (JVM) Installation of license files Fault recovery Web Browser: Any NiagaraAX station can be accessed with a standard web browser; a station contains a web service component that provides a standard servlet engine and HTTP and HTTPS support. When a browser connection is made to a NiagaraAX station, a Java web applet is downloaded to the browser cache that provides the UI components necessary for web session. Rev.1.0 Date 7/31/2017 2

3 Opus leverages the NiagaraAX framework to deliver a system architecture and set of components that provide tightly integrated enterprise to device BAS solutions capable of connecting thousands of diverse and geographically dispersed devices into well structured, seamless web-enabled systems. Component descriptions and typical system architecture diagrams are provided in the next sections. Opus BAS Component Descriptions Opus BAS component descriptions are provided below; description numbers correspond to the component numbers shown in the architecture diagrams in Section 3 that follows this section. 1. Opus Supervisor: Opus Supervisor is an enterprise application suite designed to connect hundreds or thousands of Opus building level automation systems into a single Opus BAS. Opus Supervisor provides the following set of centrally accessible management tools and services: Comprehensive graphical engineering and configuration toolset used to develop BAS applications Enterprise wide user access administration Enterprise wide time synchronization Enterprise wide Opus software version provisioning Data collection services used to collect building level BAS alerts and point histories collected data may be stored in a local data repository (smaller systems) or loaded into an MS SQL database (recommended in enterprises that have 200 or more connected buildings) Batch services that allow central management of building BAS control system parameters and operation schedules Building BAS alert management providing alert routing via , SMS, etc. Built-in web-server Enterprise navigation interfaces for remote users connecting to the BAS via web-browser or Opus Architect (see below). Opus Supervisor is designed to run on a Windows server, its NiagaraAX platform daemon runs as Windows service and its applications and services run in its station; Opus Supervisor also incorporates workbench. 2. Opus XCM: The Opus XCM is a building level embedded controller/server platform that acts as the building s BAS executive, providing the following functionality: Acts as the IP connected access point for enterprise level user interaction and Opus Supervisor data exchanges Provides and acts as communication manager for a local communication bus that connects building level equipment controllers into the BAS Rev.1.0 Date 7/31/2017 3

4 Provides building level supervisory control, managing building equipment operating schedules and control parameters Provides building global data point communication to equipment controllers Acts as building level data collection and short term storage for BAS point histories that are periodically uploaded to the enterprise BAS data repository by the Opus Supervisor Acts as building level alarm manager and enterprise gateway acting to implement alarm rules in real-time and forwarding alarm data to the Opus Supervisor for reporting and long term storage in the BAS data repository The Opus XCM supports communication with Novar legacy controllers using the Novarnet protocol, and can communicate with third party equipment controllers using the BACnet, or Modbus communication protocols The platform daemon runs natively on the Opus XCM, and XCM applications and services run in the Opus XCM s station. 3. Opus Architect: Thick client desktop application used by Opus application developers and system users working on building level BAS development and configuration. Opus Architect provides an application toolset identical to that provided in Opus Supervisor, extending the Opus Supervisor s capabilities to user desktops and eliminating the need for remote desktop connections to the Opus Supervisor s host server when the need arises to access the Opus application toolset. Opus Architect provides users with all of the following: Comprehensive set of graphical user interfaces and navigation tools allowing users to conduct building level BAS monitoring and management operations, and view point history data from across the Opus BAS Extensive graphical engineering and configuration toolset used to develop and update site BAS applications Access to the Opus Supervisor s BAS enterprise user access administration services Batch management toolset used to manage building BAS control system parameters and equipment operating schedules from the enterprise level Alarm console providing comprehensive views of current and past alarm activity across the enterprise BAS Comprehensive set of report development tools allowing users to develop custom reports on any available BAS data, and to create customized exception reports Opus Architect is designed to run on a Windows workstation, its NiagaraAX platform daemon runs as Windows service and its applications and services run in its station; Opus Architect also incorporates workbench. 4. Opus Browser Access: Users can connect to the Opus BAS through a webbrowser - a browser connection can be made to the Opus Supervisor, in which case enterprise navigation interfaces can be accessed and used to launch browser sessions with building level Opus XCMs. A browser connection can also be made directly to a site XCM. Rev.1.0 Date 7/31/2017 4

5 Opus browser access provides users with the following functionality: Comprehensive set of graphical user interfaces and navigation tools used for building level BAS monitoring and management operations, and viewing point history data from across the enterprise BAS Alarm console providing comprehensive views of current and past alarm activity at the building and across the enterprise BAS Access to site and enterprise level history data 5. Opus Data Manager: Dedicated server based suite of data collection applications, Opus Data Manager provides a flexible software framework that serves as host for a set of data collection applications - data collection applications may be added as necessary to meet enterprise data collection requirements. The following data collection applications are provided in Opus Data Manager: History Application: collects point histories from remote site BAS panels at scheduled times during the day and loads collected history data into an SQL database. Alarm Application: receives BAS alarms from remote site BAS panels as they occur and loads collected alarm data into an SQL database. Meter Manager Application: collects time-series electrical consumption data stored at a site smart electrical meter, and generates a CSV file that can be accessed by an external web application using a web-services interface; data is stored at the site meter in one minute intervals and collected by the Meter Manager Application in near real-time. Opus Data Manager is designed to run on a Windows server with its platform daemon running as Windows service, and data collection applications and related services run in their own stations. Opus Data Manager also runs workbench. 6. Opus MS SQL Database: Opus Supervisor has a native data storage repository that stores collected alarm and point history data at the Opus Supervisor host, and makes data available through Opus Supervisor UIs for a set of structured reports that are provided, and for ad-hoc viewing and export to external applications like MS Excel For larger systems (typically more than 300 connected Opus XCMs), an Opus Data Manager is required, and is configured to write collected BAS alerts and data point histories into an MS SQL relational database, a driver is provided to setup connection and login to an MS SQL Server serving as host for Opus databases. Alerts detected at the Opus XCM (building level BAS) are sent to the Opus Data Manager immediately and written to the Opus MS SQL database upon receipt. BAS data point histories stored at Opus XCMs are collected periodically by the Opus Data Manager and written to the database. Alerts and data point histories may be stored in the same database, or in separate databases. Rev.1.0 Date 7/31/2017 5

6 Opus Architecture Diagrams Opus components are selected and deployed in combinations necessary to meet project specific requirements. The simple diagrams below show several typical Opus BAS system architecture schemes. Figure 1 - Smaller deployment using Opus Supervisor s local data repository for history and alarm storage: Rev.1.0 Date 7/31/2017 6

7 Figure 2 - Smaller deployment using MS SQL for history and alarm data storage: o Figure 3 - Larger deployment (>200 connected Opus XCMs) with Opus Data Manager writing history and alarm data collect from Opus XCMs into MS SQL databases. Rev.1.0 Date 7/31/2017 7

8 Figure 3 - Larger deployment (>200 connected Opus XCMs) with Opus Data Manager writing history and alarm data collect from Opus XCMs into MS SQL databases. Rev.1.0 Date 7/31/2017 8

9 Opus Communicating and Networking Three primary network communication protocols are used in an Opus BAS, each is native to the NiagaraAX framework, network protocols are used to connect and integrate the Opus BAS components described in Section 2 above, and to provide user web-browser access. A simple networking illustration is provided in Figure 4 below followed by protocol descriptions. Figure 4 Rev.1.0 Date 7/31/2017 9

10 Opus BAS Protocol Descriptions: 1. Niagarad(s): proprietary NiagaraAX protocol used for workbench to platform daemon communication. 2. Fox(s): proprietary NiagaraAX multiplexed peer to peer protocol on a TCP connection; the Fox protocol is used for station to station and Workbench to station communication. The Fox protocol has these features: Layered over a single TCP socket connection Digest authentication (username/passwords are encrypted) Peer to peer Request/response Asynchronous events Streaming Ability to support multiple applications over a single socket via channel multiplexing Text based framing and messaging for easy debugging Unified message payload syntax Java implementation of protocol stack 3. HTTP(S): Standard protocol used by web-browsers to access web pages from a station; when a browser connection is made to a station, a Java web applet is downloaded to the user host that provides session UI modules that are cached on the host machine. Fox and HTTP Tunneling Normally, users connect directly to a station using Opus Architect or a web-browser. In some cases it may be necessary to allow users that don t have network access to Opus XCMs at the building level to access the XCMs through Opus Supervisor. This arrangement is referred to as tunneling Opus Supervisor acts as a proxy server when tunneling is used. An important caveat to consider when using tunneling is that HTTPS is not supported between the Opus Supervisor and Opus XCM (refer to the data security section below for more on secure communications). Rev.1.0 Date 7/31/

11 System Requirements Opus deployments are engineered to meet individual enterprise needs, and system requirements for Opus Supervisor and Opus Data Manager vary based BAS size (connected Opus XCMs), data collection requirements, and user load. The system requirements presented in this section can be used for planning purposes, but we strongly recommend working closely with a Novar representative to develop an infrastructure plan that will work for your implementation. Software Operating Systems: Application Computer Class Supported Operating Systems Opus Supervisor (32-bit), Opus Architect Opus Supervisor (32 and 64-bit), Opus Data Manager Workstation Server Windows 7 (32 and 64 bit), Windows 10 (64 bit) Windows Server 2003, Windows Server 2008, Windows Server 2012 Java VM Versions for Opus Supervisor, Opus Architect, and ODM Opus uses the Java VM as a common runtime environment across all supported operating systems and host hardware platforms. The Opus Supervisor and Opus Architect require J2SE 1.6 VMs at minimum. Web-Browsers and JRE Versions Novar recommends using Internet Explorer 10 or 11 as the web-browser used to connect to an Opus BAS. Firefox and Google Chrome have been used successfully in Opus deployments, but are not included in Novar product testing and may therefore prove unreliable. Browser connections in Opus require the Java Runtime Environment (JCE) to be running on the browser host computer. Novar supports and strongly recommends use of an up to date Java SE version on the browser host computer, Java versions older than Java SE 7 update 7.45 are known to have security vulnerabilities and are not supported as a result. In addition to running an up to date Java SE version, the addition of the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files to the computer s Java deployment is required. JCE can be downloaded from the Oracle Java website. While Novar does not support use of older Java versions, it is understood that use of an older Java version may be required for older applications in an enterprise. In these cases, Novar staff can assist and developing a workable deployment strategy, but Java SE versions older than Java SE 7 update 45 are not officially supported and can be difficult to work with in Opus. Rev.1.0 Date 7/31/

12 Relational Databases Opus supports the following relational database management systems (RDBMS) for storage of BAS alarm and history data: Microsoft SQL Server/MS SQL SQL Server 2005 SQL Server 2008 SQL Server 2012 Note: Novar does not provide Microsoft SQL Server as a part of a customer on premise Opus BAS deployment. In cases where Novar is collecting BAS data from a customer on premise Opus BAS for reporting and analysis as a part of a service agreement, Novar does provide the necessary SQL Server in our environment. Hardware Requirements Opus Architect: System Component Minimum Recommended Memory 8GB 16GB Processor(dual-core) 2.00 GHz 2.50 GHz Hard Disks & Available Storage 100GB >100GB Rev.1.0 Date 7/31/

13 Opus Supervisor: No. of Sites Concurrent Users <= System Component Minimum Recommended Memory 16GB 32GB Processor(quad-core) 2.00 GHz 2.50 GHz Hard Disks & Storage 100 GB >100GB 200 to to to Memory 16GB 32GB Processor(quad-core) 2.50GHz 3.00GHz Hard Disks & Storage 100GB >100GB Memory 32GB 64GB Processor(quad-core) 2.50GHz 3.00GHz Hard Disks & Storage 100GB >100GB Memory 64GB 64GB Processor(quad-core) 3.00GHz 3.00GHz Hard Disks & Storage 100GB >100GB Rev.1.0 Date 7/31/

14 Opus Data Manager Deployment Scenarios Opus Data Manager (ODM) hardware requirements depend on required data throughput. ODM provides data collection applications as described in the component descriptions section above. The tables below provide ODM deployment scenarios and associated hardware requirements and recommendations: ODM Deployment Scenarios: Connected Opus XCMs Connected Meters History Apps Alarm Apps Meter Mgr Apps Deployment Scenario up to up to up to 500 up to to to to to to to to to to to to to Notes: 1. The above assumes 500 logged points per XCM logged at 15 minute intervals 2. Deployment scenarios where connected XCM and meter counts exceed the counts shown for scenario 4 in the table above require an additional ODM server(s). Rev.1.0 Date 7/31/

15 ODM Hardware Requirements/Recommendations: Deployment Group ** System Component Minimum Recommended Memory 16GB 32GB Quad-Core Processor 2.00 GHz 2.50 GHz Hard Disks & Storage 100GB >100GB Memory 32GB 64GB Quad-Core Processor 2.50GHz 3.00GHz Hard Disks & Storage 100GB >100GB Memory 32GB 64GB Quad-Core Processor 3.00GHz 3.00GHz Hard Disks & Storage 100GB >100GB Memory 64GB 64GB Quad-Core Processor 3.00GHz 3.00GHz Hard Disks & Storage 100GB >100GB IT Configuration Details Default TCP/IP Ports The following default TCP/IP ports must be opened in firewalls between Opus components in the Opus BAS, these ports can be changed if necessary: Service Default port Niagaraad 3011 Niagaraad (secure) 5011 Fox 1911 Foxs (secure) 4911 HTTP 80 HTTPS (secure) 443 LDAP 389 LDAP (secure) 636 MS SQL Server 443 Rev.1.0 Date 7/31/

16 Windows Active Directory Permissions Initial installation and configuration of Opus software on a Windows computer requires local admin permissions as does implementing software upgrades. These tasks occur infrequently; most user activities require Windows standard user permissions only. In some instances, company security policies may restrict user permissions beyond the user restrictions applied under the Windows standard user profile, in these cases security policy exceptions may be necessary to ensure users have the permissions they need for various activities in Opus. The table below provides a description of various common user activities in an Opus BAS along with required Window active directory permissions: Activity Initial software installation Software license install Software upgrades Restart platform daemon Create and sign SSL certificates Platform administration Platform TCP/IP configuration Restart application Connect to host platform Create new XCM application program from template Download application program to deployed Opus XCM Commission deployed Opus XCM Backup deployed Opus XCM program Run control parameter or schedule update batch job Run history data collection job Auto discover and import deployed Opus XCM Access user service Access LDAP/Active directory user service Default port local admin local admin local admin local admin local admin local admin local admin standard user standard user standard user standard user standard user standard user standard user standard user standard user standard user standard user Host IP addressing Opus hosts may use either static IP addressing, or dynamic addressing using DHCP. All Opus hosts support DHCP. Since Opus hosts communicate with one another, using static IP addresses is recommended. DHCP can be used reliably in an Opus BAS deployment if a static DHCP address is reserved for the MAC address for each Opus host. DNS is supported and used frequently in Opus BAS deployments as alternative to using IP addresses. Rev.1.0 Date 7/31/

17 Data Security Opus supports data encryption for all of the networking protocols described above using the NiagaraAX implementation of the industry-standard Secure Socket Layer (SSLv3) and Transport Layer Security (TLSv1) protocols. Data encryption provides server authentication and encryption of data transmitted between client and server to provide: Secure Platform - Niagarad over SSL Secure Fox Service - (Foxs) Secure Web Service - HTTP over SSL (HTTPS) Secure communication implementation provides authentication for communication between Opus components and encryption of transmitted data. An extensive SSL toolset is provided to allow customized deployment based on individual enterprise security compliance requirements. The toolset has these features: Allows creation of self-signed server certificates Provides certificate management for server and Certificate Authority (CA) certificates (third-party or company-signed certificates may be used), and these functions are supported: Certificate Signing Requests (CSR) may be generated Tools are provided for installation and management of certificates Tools for management of trusted CA certificates are provided An Allowed Hosts list is provided for manually controlling the hosts (servers) to which a client can connect with a certificate that has not been validated (no matching certificate exists in the client's Trust Store) A certificate signing tool is provided Provides outgoing security Deployment documentation is available from Novar, and Novar technical representatives are available to assist in planning and implementing an effective data encryption scheme based on security compliance requirements. User Management Opus includes a comprehensive security model based on the NiagaraAX security implementation; the model is designed to provide a high degree of flexibility in managing user access privileges in Opus Supervisor, Opus Data Manager, Opus Architect, and Opus XCM. The security model addresses both the platform and station connections as described below: Rev.1.0 Date 7/31/

18 Platform Connection: A platform daemon connection can be made on any Opus host (Supervisor, Data Manager, Architect, or XCM); this connection is typically made by administrative users requiring access to the platform configuration utilities described in Section 2 above. A platform connection uses host-level authentication (user s Windows Active Directory credentials) for Opus software running on a Windows computer, and uses a private administrator password for user access to an Opus XCM s platform. Station Connection: Station connections to Opus Supervisor, Opus Data Manager, Opus Architect, or an Opus XCM are made by most Opus users, providing access to applications and services used in day-today BAS monitoring and management activities. Users connecting to Opus Supervisor or an Opus XCM using a web-browser are typically connecting to the station. Opus provides a comprehensive station user management toolset that provides a high degree of flexibility in managing user permissions based on user roles and associated access requirements. User categories can be created that define access privileges for classes of users, and then users can be added to a category that has been created to have the category s access privileges applied. Use of strong passwords can be enforced, and password strength parameters (password length, number of required special characters, number, (upper/lower case characters) can be configured. Station Password Storage Starting at Opus version 5.11, hashed or encrypted (AES-256) formats are used to store passwords in an Opus station's database: Hashed: A hash of the passwords created with a cryptographically-strong, one-way, algorithm (PBKDF2-HMAC-SHA256) is stored; with this method passwords that do not need to be transmitted to other systems or servers, LDAP servers for example. Encrypted (AES-256): Some station services need to store passwords in order to communicate to other systems such as servers, LDAP servers; for these passwords, a strong, two-way encryption algorithm like AES-256 is used where the encryption key used is stored separately from the station database file (config.bog); an attacker with access to the station file cannot learn the passwords it contains. LDAP/Active Directory Integration Opus supports integration with Active Directory and other LDAP directory services (Apache Directory Server and OpenLDAP are examples). Active Directory (AD) is the Microsoftsupplied directory service used on many Windows domain networks - AD utilizes LDAP protocols (LDAPv2 or LDAPv3) and often Kerberos for authentication, and supports an LDAP interface. With Active Directory integration P implemented, users can access an Opus station using Windows credentials. AD or other LDAP directory service integration has several advantages: Automatic creation of station user accounts upon LDAP user login Rev.1.0 Date 7/31/

19 Automatic assignment of pre-determined permissions based on user prototypes that can be created and stored in a station s database. Automatic access to useful user properties such as address and full name Network Traffic and Bandwidth Utilization Anticipating network traffic and bandwidth utilization is an important part of designing a successful Opus BAS implementation. Network traffic and bandwidth utilization depends on system activity at any given time, and will grow as an Opus BAS expands. A list of common activities that have impact follows: Initial Opus XCM setup and commissioning Commissioning and setup of an Opus XCM at the building level is a onetime activity that entails sending the building control system application to the Opus XCM, this is typically done from the Opus supervisor and is a onetime activity software upgrades and the control application configuration to the XCM. Bandwidth usage will vary during commissioning and setup according to the size of the building level control system (number of connected equipment controllers and BAS data points). Day to day user monitoring and building management activities Day to day user monitoring and management activities typically involve a user initiated connection from either an Opus Architect or web-browser client to the Opus Supervisor and then to the building level Opus XCM the client retrieves building Opus XCM connection details and then connects directly to the Opus XCM. A direct connection can be made from the client to an Opus XCM as well, though this is less common. Point History Collection The Opus Supervisor (<200 connected Opus XCMs) or Opus Data Manager is configured to periodically retrieve BAS point history data collected by and stored at the Opus XCM this history data retrieval (referred to history import) is set to occur once each day over a defined time range, usually during off-hours when user activities are at a minimum. Alarm Collection Alarm reporting traffic is data sent when alarm conditions within the XCM site controllers are detected. The alarm messages are optionally sent to the Opus Supervisor to be reported and archived. The number and frequency of these alarm messages depends on how aggressively the alarm set-points are configured within the XCM controllers. Rev.1.0 Date 7/31/

20 Opus XCM application updates Opus XCM application updates are necessary from time to time this involves a connection from the Supervisor to the XCM, and is typically implemented with a batch update tool that can automatically send updates to groups of Opus XCMs. Opus XCM software updates Opus XCM software updates are necessary from time to time as is the case with application updates, this process involves a connection from the Supervisor to the XCM, and is typically implemented using a batch update tool that can automatically send updates to groups of Opus XCMs. Software and application updates are normally done at the same time, and are planned in advance updates are typically planned for implementation when user monitoring and management activities are expected to be at a minimum. Nominal Bandwidth Usage Activity Opus XCM setup and commissioning Day to day monitoring and site management Site BAS point history collection Site alarm reporting Batch setpoint / schedule management Opus XCM application updates Opus XCM software updates Default port ~10 kbit/sec usage with 1-2 sec peaks at 3 Mbit/sec bursts History and Alarm Database Growth and Capacity Requirements BAS alarm and history data collected at the Opus Supervisor or Opus Data Manager can be written to a local file structure or written to and stored in an MS SQL database or databases (history data can be stored in one database and alarm data in another). Local file structure data storage is appropriate for small Opus BAS deployments only. Adding an Opus Data Manager running in its own server environment, and configuring the ODM history and alarm applications to write data to a SQL database or databases is strongly recommended large scale data collection is resource intensive and failure to follow this deployment recommendation is likely to result in system performance problems. Whether using local file structure data storage or writing collected data to an MS SQL database(s), history and alarm data volumes must be estimated, and data retention policies must be determined. Rev.1.0 Date 7/31/

21 History Database Size Estimating A point history can have any of these history extension types in an XCM application: History Point Extension type Data type bytes per history record OpusNumericIntervalHistoryExt numeric interval OpusBooleanIntervalHistoryExt binary (true/false) interval OpusEnumIntervalHistoryExt enumerated interval OpusStringIntervalHistoryExt string interval OpusNumericCOVHistoryExt numeric change of value OpusBooleanCOVHistoryExt Binary (true/false) change of value OpusEnumCOVHistoryExt enumerated change of value OpusStringCOVHistoryExt string change of value Point histories also have a logging interval (the interval at which data values are captured and stored at the Opus XCM). Point histories can also be captured using change of value (each change of value is recorded and time stamped), this data capture method is typically not used in an Opus BAS. History data volumes can be estimated using these steps: Start by making counts of point histories required in a typical Opus XCM application in the Opus BAS make separate counts for point histories the have the same history extension and logging interval, as an example the result set might look like this: History Point Extension type Logging Interval (minutes) Count OpusNumericIntervalHistoryExt OpusNumericIntervalHistoryExt OpusBooleanIntervalHistoryExt OpusBooleanIntervalHistoryExt OpusStringCOVHistoryExt Rev.1.0 Date 7/31/

22 Next determine how many samples will be captured for each group each day; this can be done by dividing the number of minutes in a day by the group s logging interval, and multiplying the result by the group point count. Columns have been added to the above table to show what the result will look like: History Point Extension type Logging Interval (minutes) Count Intervals per day Total captured values per day OpusNumericIntervalHistoryExt ,200 OpusNumericIntervalHistoryExt ,400 OpusBooleanIntervalHistoryExt ,400 OpusBooleanIntervalHistoryExt ,200 OpusStringCOVHistoryExt Adding total captured values per day will provide the total number of data inserts that will need to be processed by the RDBMS each day for a single XCM, multiplying the total captured values per day for a single XCM by the number of XCMs in the BAS will provide the total number of inserts that will need to be processed each day by the RDBMS. Continuing our example, the table we ve constructed now looks like this: History Point Extension type Logging Interval (minutes) Count Intervals per day Total captured values per day OpusNumericIntervalHistoryExt ,200 OpusNumericIntervalHistoryExt ,400 OpusBooleanIntervalHistoryExt ,400 OpusBooleanIntervalHistoryExt ,200 OpusStringCOVHistoryExt Total daily database inserts 25,220 25,200 * 300 XCMs = 7,566,000 daily database inserts. Rev.1.0 Date 7/31/

23 The table below can be used to calculate database growth over time when the local file structure is used for BAS history data storage: History Point Extension type file header byte size bytes per history record OpusNumericIntervalHistoryExt OpusBooleanIntervalHistoryExt OpusEnumIntervalHistoryExt OpusStringIntervalHistoryExt OpusNumericCOVHistoryExt OpusBooleanCOVHistoryExt OpusEnumCOVHistoryExt OpusStringCOVHistoryExt The following table can be used to estimate MS SQL database initial size and incremental growth: Category Create empty database Add Opus tables Incremental growth Estimating method 2mb 2mb (total inserts per day) / 112 * 8192 = bytes Sizing illustration: For 1 day logs for 1 site with 175 points x 96 intervals per day: History table size = (175*96) / 112 * 8192 = 1.228,800 bytes per day per site Therefore, for an example of 100 sites for a full one year without maintenance, the database size would grow to: 1.228,800 * 100 * 365 = ~ 44,851,200,000 (44.8 GByte) / year Rev.1.0 Date 7/31/

24 Alarm Database Sizing Estimating As is the case with history database processing and size estimation, estimating alarm database incremental growth starts with estimating the number alarms that will be generated each day from XCMs in the Opus BAS enterprise. Since alarms occur unexpectedly, an average number of alarms for each XCM must be assumed. An estimate can be made by evaluating alarm traffic in a legacy building automation system if the Opus BAS will be replacing it; an average daily alarm volume estimate can be made by looking at alarm traffic in initial Opus XCM installation in an Opus BAS. Once a daily alarm count estimate has been made, an incremental database growth estimate can be made using the information below: Data storage Category bytes/alarm record Local file structure Incremental growth 4090 Create alarm database 2mb MS SQL Create database schema 2mb Incremental growth 1750 MS SQL Database Permissions Initial database creation requires database and table create permissions. These tasks are frequently done by a database administrator in the enterprise IT staff. Once database creation has been completed and the database schema has been setup, the Opus needs permission to create new records in the database (insert BAS data), to execute stored procedures, and to submit database queries (read data). MS SQL Table Partitioning and Compression Database tables may be partitioned and compressed to improve query performance in large BAS databases. Recommended practices are documented in Opus BAS help files, and Novar staff can assist in planning an effective implementation strategy. Remote Network Connectivity When planning for an Opus BAS deployment consideration must be given as to how users will connect to the BAS when they are not connected to the company network that the BAS resides on. There are typically three classes of users that will need to make remote network connections: Novar application engineering staff responsible for providing support for initial software installations and configuration, and for creating, downloading and commissioning building level Opus XCMs Internal company employees that will need to access the Opus BAS when they are not connected to the company network (nights and weekends). Novar post installation monitoring and support staff responsible for providing remote technical assistance and issue investigation and resolution. Rev.1.0 Date 7/31/

25 Remote network connections are accomplished by creating a secure VPN that will provide remote user access to permitted BAS resources. Novar strongly recommends use of a site to site VPN to accommodate the support activities conducted by remote staff. It s important to keep in mind when considering a remote network solution that Novar support activities require a network to network connection rather than a remote user to network connection support activities require that Novar staff be able to access the remote Opus BAS without losing easy access to Novar network drives where technical support information is stored and managed. Novar s IT support staff has extensive experience in effective implementation of site to site VPN solutions that ensure compliance with customer network security policies while ensuring that external support staff are able to provide the highest possible level of implementation support and service - a collaborative approach in VPN design is essential to ensuring a successful Opus BAS implementation. Document Revision History Revision Date Issued Reason for Change JULY-17 Original Release The material in this document is for information purposes only. The content and the product it describes are subject to change without notice. Honeywell makes no representations or warranties with respect to this document. In no event shall Honeywell be liable for technical or editorial omissions or mistakes in this document, nor shall it be liable for any damages, direct or incidental, arising out of or related to the use of this document. No part of this document may be reproduced in any form or by any means without prior written permission from Honeywell. Copyright 2017 by Honeywell International, Inc. All Rights Reserved. Honeywell I 6060 Rockside Woods. Blvd., Suite 400 I Cleveland, OH I Phone: I Rev.1.0 Date 7/31/