Total Property Optimization (TPO) System Design

Total Property Optimization (TPO) System Design Specifications Document - August 2014 -

Center for Computational Learning Systems Columbia University

1 of 105

Current Table of Contents: 1. Total Property Optimization (TPO) Planned Development 2. TPO Framework (Components and Architecture) 3. Quality Assurance 4. Configuration Management 5. Software Requirements 6. Process Flow for Send and Receive Components 7. General Installation Instructions 8. Electric Tenant Load Predictor Component Instructions 9. Electric Predictor Component Instructions 10. Space Temperature Predictor Component Instructions 11. Steam Usage Predictor Component Instructions 12. Weather Component Instructions 13. Startup and Ramp Down Recommendation Space Temperature Trajectory Component Instructions 14. Topic Discussion on Preheating Recommendations 15. Preheating Recommendations Component Instructions 16. Occupancy Predictions Instructions 17. Topic Discussion on Now-Cast Recommendations 18. Web Component Instructions 19. Appendix - Issue Tracking and Change Management – Redmine

2 of 105

1. Total Property Optimization (TPO) Planned Development Columbia University’s Center for Computational Learning Systems (CCLS) is working with Finmeccanica/Selex and Rudin Management to develop an integrated intelligent building portfolio management and operation support system called SPMS. CCLS’s contribution includes the research, development, and deployment of a SPMS subsystem called the Total Property Optimization (TPO) system. TPO is an effective machine learning technology that analytically monitors and learns critical building environmental behaviors and makes recommendations to optimize performance by building operations to maintain correct environment levels with economic benefits. TPO efficiently learns via analysis of massive data collected from an expressive range of environmental sources and sensors distributed throughout one or more buildings. TPO working as an integrate component in the SPMS architecture: (1) receives access to massive building environmental data sets along with weather data sets, and (2) transmits data and recommendations across the SPMS architecture to such operations subsystems as the SPMS/SIF Server and SPMS Building Manager dashboard.

1.1 Planned Functions TPO receives data feeds input from the SPMS SIF Server, conducts machine learning based data analytics, generates forecasting outputs and decision recommendations, and sends this data and recommendations to the SIF Server. Key functions performed by the TPO include: (1) real time and continuous monitoring of space temperature, steam and power usage demand/consumption using variation from normal or forecasts provide a combined space temperature horizon indicator graphical user interface (GUI) component to display on the SPMS Building Manager dashboard as a window (2) an energy forecasting module: display next day’s forecast and scoring of previous forecasts in the TPO display as a drilldown --- Steam or Electric can be selected for the “yesterday, today, and tomorrow window on the main SPMS Building Manager dashboard (3) generate start-up timing recommendations based on space temperatures electric, and/or steam forecasts to display as a message. (4) generate reasonable HVAC start-‐up and timing recommendations by EOB of day before as a message (5) pre-heating of the buildings during the utility winter steam demand period will need to be addressed; system needs to evaluate the cost of preheating the water systems versus the exposure to excess demand changes incurred by starting during on-‐peak time period

3 of 105

(6) metrics module: display appropriate real-‐time scoring metrics evaluating TPO performance and building behavior under each TPO chart (7) generate ramp-‐down timing recommendations based on occupancy, as well as electric usage and weather changes for the initial system (8) perform now casting of temperature prediction every hour for next two hours (9) planning the addition of modeling alternative energy, storage, electric vehicle charging and/or Space Temperature options for optimizing building performance and timing.

2. The TPO Framework What makes the TPO system unique is how sets of diverse machine learning components work individually and in collaboration together in order to formulate & forecast predications and generate recommendations. The framework is like a matrix of components, functioning as independent intelligent machine learning “software agents” that provide useful insights to each other. Let’s first consider the baseline forecasting components. There are distinct machine learning components that process significant amounts of building temperature/environmental data regulated by such building climate control resources as steam or electric. Examples of these environmental forecasting components include: electric load forecaster tenant electric load forecaster steam forecaster space temperature forecaster These four core machine learning components observe and learn building climate behaviors as influenced by a building climate control resource, such as electric. As these climate behaviors are learned by these core components, their machine learning actions generate models of the building’s climate behavior that in turn can be leveraged to make predictions of near term future climate outcomes within a building. These core predictive models in turn are then applied by other machine learning components to provide sophisticated results and recommendations for a building’s operations staff and engineers to use to be proactive and cost effective in maintaining desired environmental results throughout a building. Another important component that complements all the other machine learning components is the weather forecasting component. This component makes use of several weather data sources that indicate future probable weather patterns. Data output from this component is used across all the TPO machine learning components as they classify and generate their predictive models. For example, learning a building’s temperature behavior based on historical usage of electricity and correlating the electric consumption with specific prior weather conditions, enables a machine learning component to generate a predictive model. This model represents probable

4 of 105

building environmental outcomes (e.g., temperatures) resulting from discrete amounts of electric consumption to obtain a desired building temperature to address a predicted weather condition that will occur in the near future. Two machine learning components that leverage the models and outputs of the other components in the TPO framework address Startup and Ramp Down of a building’s climate control resources (e.g., electric, steam, etc…). These two components, the Startup Recommender and the Ramp Down Recommender, learn building behaviors with regards to optimal startup and ramp down times to bring building environmental resources online/offline to achieve desired environmental results (e.g., temperature) at an effective economic cost. What is important with regards to the TPO framework is the collaboration of functions performed by the other machine learning components to provide a diversity of model data that the Startup and Ramp Down machine learning recommender components use to learn and generate optimization models and recommends. These recommendations serve to assist building operations and engineering in their future planning and daily activities. 2.1 TPO Components and Architecture Currently, the TPO system is being designed to comprise four functional forecasting components that apply machine learning over time series data addressing: electric load, tenant electric load, steam, space temperature. The recommender uses the forecast to recommend actions to be taken by the operator. The recommender produces suggested start up and ramp down times. In addition a now cast module produces a 2-to-4 hour short term NowCast as an aid to the operator. (See section 15.) In addition there are weather forecasting and observation tasks that periodically retrieve data using the Weather Underground API . Each of the four forecasting components for electric, tenant electric, steam, and space temperature, are designed to perform two functions: prediction and learning parameter optimization with the prediction function performed hourly and the optimization function performed daily. The content in Table 1 (see below) provides examples of task naming for each function.

5 of 105

Table 1: List of scheduled tasks functions performed by TPO from the Windows Task Scheduler Interface

The diagrams below, Figures 1A, 1B, and 1C, represent the basic internal processes performed for each respective TPO component addressing one of the various functions such as electric, tenant electric, steam, and space temperature. For example, the EPRED component for electric load prediction involves: (1) a process to “clean” the input data from the building systems and sensors; this data is processed to obtain covariates, variables exhibiting correlated variation (2) the covariates are then applied by a task specific TPO Support Vector Machine (SVM) performing analytical machine learning (3) the SVM learning generates a decision model update to be applied internally by the prediction/recommendation process; the prediction(s) are represented as data stored and forwarded to the SPMS SIF which in turn posts the TPO output as updates to SPMS subsystems for storage and use by operations

6 of 105

Figure 1A. Internal TPO system architecture

7 of 105

Figure 1B. Internal TPO system architecture Startup Recommender Startup Scheduled Task (every 1 hr)

Grid Search Cross Validator

CV

Build Prediction Model (SVM) UI (.net Win App): Time series graphs of recommendations

Cross Validation Run Every Hour

Data Prep 24-Hour Prediction Layer

Covariates s

Prediction MSSQL DB Rampdown Recommender

SELEX Message Bus

Rampdown Scheduled Task (every 1 hr)

Grid Search Cross Validator

CV

Build Prediction Model (SVM)

SELEX Message Bus

Cross Validation Run Every Hour

Data Prep

Covariates s

Prediction

8 of 105

UI (.net Win App):

Preheat Recommender

Time series graphs of recommendations

Preheat Scheduled Task (every 1 hr) Weather Forecasts

Covariates

Cost Estimate

Prediction

MSSQL DB

SELEX Message Bus

Figure 1C. Internal TPO system architecture

2.2 Scheduling of analytic SVM processing The running of SVM analytics to generate decision models that enable TPO to make recommendations and predictions is currently based on various schedules to process different sets of sensor data. For example in Figure 1A, the scheduling is as follows: every hour TPO performs a SVM classification by generating a new decision model every night TPO optimizes the learning parameters for the SVM models for the following day every hour, startup and ramp down predictions are regenerated. every 15 minutes an ensemble-based nowcast prediction is run starting 7 minutes after the hour data sample rates of the sensor data is every 15 minutes 2.3 Platform and Networking supporting SPMS and TPO In progressing the development and deployment of the SPMS service, service resources in computing hardware and networking have been engineered over a global platform. The distribution of computing servers and databases, sources of input data, operational systems for monitoring, display dashboards for management, and the necessary security resources are represented in Figure 2 (see below).

9 of 105

Figure 2. Platform supporting TPO system integration within SPMS

10 of 105

3. Quality Assurance Quality assurance of TPO system is based on three levels of software testing: unit testing, system testing, and integration testing. 3.1 Unit Testing Unit testing is conducted throughout each TPO component’s development stages by the TPO team member who is responsible for that module. Testing included extensive testing of: 1. component functions with valid test data, and 2. component interfaces for all data input and output 3.2 System Testing System testing is conducted at the TPO’s system level to validate the TPO system can function as a whole and also work in a robust, online, near real time fashion. This work included testing of end-to-end system correctness and scalability with valid test data. 3.3 Integration Testing Integration testing is conducted at the stage of integrating TPO into the SPMS. The integration process focuses on data communication and its performance and robustness. This work focuses on extensive API testing of TPO interfacing with SPMS SIF.

4. Configuration Management For program source control and versioning, TPO development uses SVN server as the data repository. On the client side, TortoiseSVN for Windows is used on development machines to check in and check out program code. 4.1 How to configure TPO for Different Buildings TPO provides scripting instructions so as to allow accurate installation and configuration performance of TPO for each distinct building. Our configure file technique is managed using .ini-convention files. The configuration scripts are read by a parser (implemented in Python) and the scripts are coded in CSG file format.

11 of 105

The config file, config.ini, is partitioned into follwing sections: 1. General default settings for the TPO system 2. Configurations for each individual building 3. Configuration for each tenant of interest A utility is available which can be used to create/update the configuration file. It is located at Rudin/Install/forecasting in SVN. This tool can be used to add new sections for building, tenant or the default section to the configuration file. Usage: $python add_config_sections.py [ [ [default_section_xml]]] Points_list: Excel file for the building for which the configuration is being modified Config_file : Config file to modify Building_xml : XML file with details of settings needed for a building Tenant_xml : XML file with details of settings needed for a tenant Default_section_xml : XML file with details of settings needed for the DEFAULT section of the config file. Default XML files are available for building, tenant and default sections. The tool reads in the points list provided. It automatically populates most of the settings in the configuration files based on the points list and prompts the user for the rest. Key features of the tool: Reads in as many settings as possible from the points list automatically. Creates TPO output tables. Prompts user for settings that it is unable to set on its own Enables user to skip creating sections. This may be useful if the points list was updated, for example, a new tenant was added Warns user if the section name specified is in use. Limitations:

12 of 105

Sections can't be partially updated at this time It is recommended that a backup copy of the existing configuration file be kept at hand before using the program. The program will read in the configuration file and re-write it with new/updated settings/sections removing comments and or formatting in the process. Here is an example of a sample run of the tool:

The content provided below is an example TPO config.ini file: --- Start of Config Script --; Main configuration file for TPO project software ; Module-specific sections override the default section, and command-line ; flags override both ; Leading and trailing spaces stripped from keys and values ; Refer to another key's value with '%(key)s' ; Leave value blank for None value ; Contact a developer if you need literal '%' characters in your value ;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;; Default Settings ;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;

13 of 105

[DEFAULT] running_at = ccls ;;;; Non-relative locations ;;;; ; root of installation. Should have subdirs electric, steam, space_temp, data, etc. ;base_dir = C:/Rudin ;at Rudin it is on D base_dir = C:/Rudin ; base directory for web-accessible directories web_base_dir = %(base_dir)s/data ; program locations for use elsewhere perl_prog = c:/Perl/bin/perl.exe python_prog = C:/Python27/python.exe

;;;; other locations ;;;; ; default destination for temporary files temp_dir = %(base_dir)s/Temp ; source of static data and default dest of new models data_dir = %(base_dir)s/data ; location of static data sources data_sources_dir = %(base_dir)s/Data-Sources ; directory for control scripts control_dir = %(base_dir)s/control ; default destination for logs log_dir = %(base_dir)s/log ;;;; commands ;;;; ml_dir = %(base_dir)s/ML ;directory for Support Vector Machine programs svm_dir = %(ml_dir)s/libsvm-3.14 ;Support Vector Machine format conversion program svm_uci = %(svm_dir)s/uci2svml_reg.pl ;Support Vector Machine data normalization program svm_scale = %(svm_dir)s/windows/svm-scale ;Support Vector Machine prediction program svm_predict = %(svm_dir)s/svm-rank ;Support Vector Machine training program svm_train = %(svm_dir)s/svm-train ;Support Vector Machine weight extraction pogram svm_weight = %(svm_dir)s/svm-weight ;;;; logging configuration ;;;; ; if non-zero, calling app has already configured logger logger_configured = 0

14 of 105

; $ will be replaced with % before assignment in application code log_fmt = $(levelname)5s $(module)7s $(asctime)s: $(message)s ; top level threshold log_level = INFO ; set true to add stderr as a log device log_console = 1 ; Severity threshold for console logging ; Choose from 'CRITICAL', 'ERROR', 'WARN', 'WARNING', ; 'INFO', 'DEBUG', 'NOTSET' log_console_level = DEBUG ; message format for console log_console_msg_fmt = %(log_fmt)s ; set true to add a rotating file as a log device log_file = 1 ; severity threshold for file logging ; Choose from 'CRITICAL', 'ERROR', 'WARN', 'WARNING', ; 'INFO', 'DEBUG', 'NOTSET' log_file_level = INFO ; message format for log file log_file_msg_fmt = %(log_fmt)s ; dir for log file log_file_dir = %(log_dir)s ; mode for log file, w or a (write or append) log_file_mode = a ; max size in bytes for log file before rotation log_file_maxbytes = 5000000 ; if non-zero, number of old logs to keep log_file_backup_count = 5 ;;;; misc ;;;; ; if non-zero, run in module-defined test mode test = 0 ; if non-zero, run in module-defined debug mode debug = 0 ; common settings for all buildings ; database driver to use ;This is the 2005 Server Client Use it since there are datetime issues with client 10 ;May need to download the driver db_driver = {SQL Native Client} ;at Rudin it is SQL Server Native Client 10.0 ;db_driver = {SQL Server Native Client 10.0} ; forecast granularity in minutes; this value is also used to discard input ; data to match the prediction granularity needed forecast_granularity = 15

15 of 105

; forecast length in hours forecast_length = 24 # section names for buildings specified in this file building_ids = Rudin_345Park, Rudin_560Lexington # section names for tenants specified in this file tenant_ids = KPMG, NFL, Deutsche_Bank, Ladder_Ladder # number of days of recent data to include for training. If available, data from # a year ago around the as-of-date is also used training_radius = 30 ; for debugging only; if set to 1, uses weather forecast to generate predictions use_weather_forecast = 1 [weather_central_park_nyc] ; database name weather_db = Weather ; fully-qualified database server name or IP address weather_db_server = anderson.ldeo.columbia.edu ; observed weather data table name weather_table = Observations_History ; forecasted weather data table name weather_forecast_table = Hourly_Forecast ; database user weather_db_user = rudin_db_reader ; database password weather_db_pwd = rudin_20!3$ [History_NY_KNYC] driver = {SQL Native Client} server = 192.168.99.12 ;server = anderson.ldeo.columbia.edu database = Weather UID = weather PWD = rudin_20!3$ table = Observations_History api_key = 1addc4d75f3b92bc location = NY/KNYC ;Delta in days to truncate before adding delta = 0 ;start populating for the last entry datetime if latest is used. ;If a date specified, will start from that date. start = latest ;New York Central Park location = NY/KNYC

16 of 105

start_date = latest ;'2011-01-01' # yyyy-mm-dds [Forecast_NY_KNYC] driver = {SQL Native Client} server = 192.168.99.12 database = Weather UID = weather PWD = rudin_20!3$ table = Hourly_Forecast api_key = 1addc4d75f3b92bc location = NY/KNYC ;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;; Building Configs ;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;; [Rudin_345Park] ; database name building_db = 345 ; fully-qualified database server name or IP address building_db_server = anderson.ldeo.columbia.edu ; database username db_user = rudin_db_user2 ; database password db_pwd = rud1n2013$ ; BMS used; not relevant if SIF feed available bms = Johnson Controls ; building floor to build model for; must be compliant with SIF feeds if ; SIF feed in use building_floors = F02, F04, F04, F05, F13, F18, F20, F24, F32, F38, F40 ; floor quadrant to build model for; must be compliant with SIF feeds ; if SIF feed in use floor_quadrants = CNW, CNW, CSE, CSE, CSW, CSE, CSW, CSE, CNW, CNW, CNE zones = ; model/program codes for TPO alarms sign_prog_space_temp = 001, 002, 003, 004, 005, 006, 007, 008, 009, 010, 011 ; name of table with holiday information holiday_table = Holidays ; building open hour: 0-23 building_open_hour = 7 ;building close hour: 0-23

17 of 105

building_close_hour = 19 ; weather sation to use for this building weather_station_id = weather_central_park_nyc ; results database ; results/output database name results_db = 345 ; results/output fully-qualified database server name or IP address results_db_server = anderson.ldeo.columbia.edu ; results/output database username results_db_user = rudin_db_user2 ; results/output database password results_db_pwd = rud1n2013$ # space temperature ; table name for space temp observations space_temp_tablename_format = 345---------001BMSHVATEMSPA---VAL001 ; table name for space temp predictions (output) results_table = 345---------000TPOFORTEMSPA001---001 ; table name for space temp. prediction-derived stats (output) prediction_derived_results_table = 345---------000TPOFORTEMSPA001---001_Derivative ; table name for space temp prediction error score (output) score_table = 345---------000TPOFORTEMSPA001---001_Stats ; cross-validatons results table name xval_results_table = 345---------000TPOFORTEMSPA001---001_RBF_Params ; space temp deltas table name space_temp_deltas_table = 345---------000TPOFORTEMSPA001---001_Deltas

18 of 105

# steam ; flag to indicate whether building uses steam; 1 = steam used; 0 = steam not used has_steam_supply = 1 ; static file with past steam data; this data is read first, if available, ; and the data from the table is appended to it for training steam_data_file = %(data_sources_dir)s/Steam Mlbs 345 Park.txt ; table name for steam demand observations ;steam_demand_table = RUDINSERVER_CURRENT_STEAM_DEMAND_FX70 steam_demand_table = 345---------001BMSSTEMET------VAL001 ; results table name for steam predictions (output) results_table_steam = 345---------000TPOFORSTECON001---001 ; error score table name for steam predictions (output) score_table_steam = 345---------000TPOFORSTECON001---001_Stats ; cross-validation results table name for steam preditions xval_results_table_steam = 345---------000TPOFORSTECON001---001_RBF_Params ; model/program code for TPO alarms sign_prog_steam = 012 # electric ; table name for electric demand observations electric_load_table = 345---------001BMSELEMET------VAL001 ; static file with past electric load data; this data is read first, if available, ; and the data from the table is appended to it for training electric_data_file = %(data_sources_dir)s/MACH Energy - Electric Usage Data.txt ; results table name for electric predictions (output) results_table_electric = 345---------000TPOFORELECON001---001 ; error score table name for electric predictions (output) score_table_electric = 345---------000TPOFORELECON001---001_Stats ; cross-validation results table name for electric predictions xval_results_table_electric = 345---------000TPOFORELECON001---001_RBF_Params ; model/program code for TPO alarms sign_prog_electric = 013 ; filename format for temporary files created during training; these ; files are deleted afterthe model has been created if debug is set to 0 train_covariate_filename_fmt = \w+_%s_train_fl_%s_%s_hour_(\d+)\.csv train_covariate_filename_fmt_steam = \w+_steam_demand_%s_train_hour_(\d+)\.csv train_covariate_filename_fmt_electric = \w+_electric_demand_%s_train_hour_(\d+)\.csv ; feed type {BMS, TPOSIF}: feed type for this building feed_type = TPOSIF ; flag to indicate whether to generate occupancy predictions: 1 = predict, 0 = don't predict predict_occupancy = 1 ; table name for occupancy observations occupancy_table = 345---------000SECCNTPEOBUI---VAL001 ; cross-validation results table name for occupancy predictions

19 of 105

xval_results_table_occupancy = 345---------000TPOFORPEOBUI001---001_RBF_Params ; results table name for occupancy predictions (output) results_table_occupancy = 345---------000TPOFORPEOBUI001---001 ; error score table name for occupancy predictions (output) score_table_occupancy = 345---------000TPOFORPEOBUI001---001_stats ; model/program code for TPO alarms sign_prog_occupancy = 014 ; temporary filename format for occupancy-related files train_covariate_filename_fmt_occupancy = \w+_occupancy_%s_train_hour_(\d+)\.csv ; this flag currently indicates whether to issue alarms save_results = 1 alarms_table = 345---------000TPO---ALA---001

[KPMG] ; tenant database name tenant_db = 345 ; fully qualified database server name or IP address tenant_db_server = anderson.ldeo.columbia.edu ; db username db_user = rudin_db_user2 ; db password db_pwd = rud1n2013$ ; weather station to use for this tenant weather_station_id = weather_central_park_nyc ; building open hour for this tenant building_open_hour = 7 ; building close hour building_close_hour = 19 holiday_table = ; building floors to build model for; must be SIF-compliant names tenant_floors = F02, F04 ; results database name results_db = 345 ; fully qualified results database server name or IP address results_db_server = anderson.ldeo.columbia.edu ; results database user name results_db_user = rudin_db_user2 ; results database password

20 of 105

results_db_pwd = rud1n2013$ ; table name for tenant electric load observations electric_load_table = 345---------001EMSSMAMET------40120001 ; flag to indicate whether to save aggregated (over all tenant-occupied floors) tenant load data save_tenant_data = 1 ; aggregated tenant load observations (output) electric_load_table_total = 345---------000TPOFORELETEC003---001_Tenant_load ; static file with past tenant electric load data; this data is read first, if available, ; and the data from the table is appended to it for training electric_data_file = %(data_sources_dir)s/KPMG.txt ; results table name for tenant electric load predictions (output) results_table_electric = 345---------000TPOFORELETEC003---001 ; error score table name for tenant predictions (output) score_table_electric = 345---------000TPOFORELETEC003---001_stats ; cross-validation results table name for tenant predictions xval_results_table_electric = 345---------000TPOFORELETEC003---001_RBF_Params ; model/program code for TPO alarms sign_prog = 015 ; temporary filename format for tenant-related files train_covariate_filename_fmt_electric = \w+_electric_demand_tenant_%s_train_hour_(\d+)\.csv ; this flag currently indicates whether to issue alarms save_results = 1 alarms_table = 345---------000TPO---ALA---001 [NFL] tenant_db = 345 tenant_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ weather_station_id = weather_central_park_nyc building_open_hour = 7 building_close_hour = 19 holiday_table = ; building floors to build model for tenant_floors = F05, F06, F07, F08 results_db = 345 results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$

21 of 105

electric_load_table = 345---------001EMSSMAMET------40132001 save_tenant_data = 1 electric_load_table_total = 345---------000TPOFORELETEC001---001_Tenant_load electric_data_file = %(data_sources_dir)s/nfl.txt results_table_electric = 345---------000TPOFORELETEC001---001 score_table_electric = 345---------000TPOFORELETEC001---001_stats xval_results_table_electric = 345---------000TPOFORELETEC001---001_RBF_Params train_covariate_filename_fmt_electric = \w+_electric_demand_tenant_%s_train_hour_(\d+)\.csv ; model/program code for TPO alarms sign_prog = 016 ; this flag currently indicates whether to issue alarms save_results = 1 alarms_table = 345---------000TPO---ALA---001

[Blackstone] tenant_db = 345 tenant_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ weather_station_id = weather_central_park_nyc building_open_hour = 7 building_close_hour = 19 holiday_table = ; building floors to build model for tenant_floors = F32 results_db = 345 results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ electric_load_table = 345---------001EMSSMAMET------40120002 save_tenant_data = 1 electric_load_table_total = 345---------000TPOFORELECON001---001_Tenant_load_Blackstone electric_data_file = %(data_sources_dir)s/blackstone.txt results_table_electric = 345---------000TPOFORELECON001---001_Blackstone score_table_electric = 345---------000TPOFORELECON001---001_Blackstone_stats xval_results_table_electric = 345---------000TPOFORELECON001---001_Blackstone_RBF_Params train_covariate_filename_fmt_electric = \w+_electric_demand_tenant_%s_train_hour_(\d+)\.csv ; model/program code for TPO alarms sign_prog = 017

22 of 105

; this flag currently indicates whether to issue alarms save_results = 1 alarms_table = 345---------000TPO---ALA---001 [Ladder_Ladder] tenant_db = 345 tenant_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ weather_station_id = weather_central_park_nyc building_open_hour = 7 building_close_hour = 19 holiday_table = ; building floors to build model for tenant_floors = F08 results_db = 345 results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ electric_load_table = 345---------001EMSSMAMET------40132001 save_tenant_data = 1 electric_load_table_total = 345---------000TPOFORELETEC004---001_Tenant_load electric_data_file = %(data_sources_dir)s/Ladder and Ladder.txt results_table_electric = 345---------000TPOFORELETEC004---001 score_table_electric = 345---------000TPOFORELETEC004---001_stats xval_results_table_electric = 345---------000TPOFORELETEC004---001_RBF_Params train_covariate_filename_fmt_electric = \w+_electric_demand_tenant_%s_train_hour_(\d+)\.csv ; model/program code for TPO alarms sign_prog = 018 ; this flag currently indicates whether to issue alarms save_results = 1 alarms_table = 345---------000TPO---ALA---001 [Deutsche_Bank] tenant_db = 345 tenant_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ weather_station_id = weather_central_park_nyc building_open_hour = 7

23 of 105

building_close_hour = 19 holiday_table = ; building floors to build model for tenant_floors = F14, F24, F25, F26, F27 results_db = 345 results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ electric_load_table = 345---------001EMSSMAMET------40120001 save_tenant_data = 1 electric_load_table_total = 345---------000TPOFORELETEC002---001_Tenant_load electric_data_file = %(data_sources_dir)s/Deutsche Bank.txt results_table_electric = 345---------000TPOFORELETEC002---001 score_table_electric = 345---------000TPOFORELETEC002---001_stats xval_results_table_electric = 345---------000TPOFORELETEC002---001_RBF_Params train_covariate_filename_fmt_electric = \w+_electric_demand_tenant_%s_train_hour_(\d+)\.csv ; model/program code for TPO alarms sign_prog = 019 ; this flag currently indicates whether to issue alarms save_results = 1 alarms_table = 345---------000TPO---ALA---001

[Rudin_560Lexington] building_db = 560 building_db_server = anderson.ldeo.columbia.edu bms = Schneider db_user = rudin_db_reader db_pwd = rudin_20!3$ ; building floor to build model for building_floors = F02, F05, F09, F11, F12, F15, F20, F21, F22 ; floor quadrant to build model for floor_quadrants = ---, ---, ---, ---, ---, ---, ---, ---, --zones = sign_prog_space_temp = 001, 002, 003, 004, 005, 006, 007, 008, 009 holiday_table = Holidays building_open_hour = 7

24 of 105

building_close_hour = 19 weather_station_id = weather_central_park_nyc ; results database results_db = 560 results_db_server = anderson.ldeo.columbia.edu ;;NEW AGB results_db_user = rudin_db_reader results_db_pwd = rudin_20!3$ # space temperature space_temp_tablename_format = 560---------002BMSHVATEMSPA---VAL001 results_table = 560---------000TPOFORTEMSPA001---001 prediction_derived_results_table = 560---------000TPOFORTEMSPA001---001_Derivative score_table = 560---------000TPOFORTEMSPA001---001_Stats xval_results_table = 560---------000TPOFORTEMSPA001---001_RBF_Params space_temp_deltas_table = 560---------000TPOFORTEMSPA001---001_Deltas # steam # 1 = yes; 0 = No has_steam_supply = 0 steam_demand_table = steam_data_file = results_table_steam = score_table_steam = xval_results_table_steam = sign_prog_steam = # electric electric_load_table = 560---------002BMSELEMET------VAL001 electric_data_file = results_table_electric = 560---------000TPOFORELECON001---001 score_table_electric = 560---------000TPOFORELECON001---001_Stats xval_results_table_electric = 560---------000TPOFORELECON001---001_RBF_Params sign_prog_electric = 011 train_covariate_filename_fmt = \w+_%s_train_fl_%s_%s_hour_(\d+)\.csv train_covariate_filename_fmt_steam = \w+_steam_demand_%s_train_hour_(\d+)\.csv train_covariate_filename_fmt_electric = \w+_electric_demand_%s_train_hour_(\d+)\.csv feed_type = TPOSIF predict_occupancy = 1 occupancy_table = 560---------000SECCNTPEOBUI---VAL001 xval_results_table_occupancy = 560---------000TPOFORPEOBUI001---001_RBF_Params score_table_occupancy = 560---------000TPOFORPEOBUI001---001_Stats results_table_occupancy = 560---------000TPOFORPEOBUI001---001

25 of 105

sign_prog_occupancy = 012 train_covariate_filename_fmt_occupancy = \w+_occupancy_%s_train_hour_(\d+)\.csv ; this flag currently indicates whether to issue alarms save_results = 1 alarms_table = 560---------000TPO---ALA---001

[Rudin_40E52] ; building_db = Rudin_345Park ; building_db_server = bell.ldeo.columbia.edu building_db = 4E5 building_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ bms = ; building floor to build model for building_floors = F02, F04, F07, F13, F15, F17, F21, F24 ; floor quadrant to build model for floor_quadrants = CNO, CSO, CNO, CNO, CSO, CSO, CNO, CSO zones = sign_prog_space_temp = 001, 002, 003, 004, 005, 006, 007, 008 holiday_table = steam_demand_table = 345---------001BMSSTEMET------VAL001 building_open_hour = 7 building_close_hour = 19 weather_station_id = weather_central_park_nyc ; results database results_db = 4E5 results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ # space temperature

26 of 105

space_temp_tablename_format = 4E5---------003BMSHVATEMSPA---VAL001 results_table = 4E5---------000TPOFORTEMSPA001---001 prediction_derived_results_table = 4E5---------000TPOFORTEMSPA001---001_Derivative score_table = 4E5---------000TPOFORTEMSPA001---001_Stats xval_results_table = 4E5---------000TPOFORTEMSPA001---001_RBF_Params space_temp_deltas_table = 4E5---------000TPOFORTEMSPA001---001_Deltas # steam has_steam_supply = 1 steam_demand_table = 4E5---------003BMSSTEMET------VAL001 steam_data_file = results_table_steam = 4E5---------000TPOFORSTECON001---001 score_table_steam = 4E5---------000TPOFORSTECON001---001_Stats xval_results_table_steam = 4E5---------000TPOFORSTECON001---001_RBF_Params sign_prog_steam = 009 # electric electric_load_table = 4E5---------003BMSELEMET------VAL001 electric_data_file = results_table_electric = 4E5---------000TPOFORELECON001---001 score_table_electric = 4E5---------000TPOFORELECON001---001_Stats xval_results_table_electric = 4E5---------000TPOFORELECON001---001_RBF_Params sign_prog_electric = 010 train_covariate_filename_fmt = \w+_%s_train_fl_%s_%s_hour_(\d+)\.csv train_covariate_filename_fmt_steam = \w+_steam_demand_%s_train_hour_(\d+)\.csv train_covariate_filename_fmt_electric = \w+_electric_demand_%s_train_hour_(\d+)\.csv feed_type = TPOSIF predict_occupancy = 1 occupancy_table = 4E5---------000SECCNTPEOBUI---VAL001 xval_results_table_occupancy = 4E5---------000TPOFORPEOBUI001---001_RBF_Params results_table_occupancy = 4E5---------000TPOFORPEOBUI001---001 score_table_occupancy = 4E5---------000TPOFORPEOBUI001---001_stats sign_prog_occupancy = 011 train_covariate_filename_fmt_occupancy = \w+_occupancy_%s_train_hour_(\d+)\.csv

; this flag currently indicates whether to issue alarms save_results = 1 alarms_table = 4E5---------000TPO---ALA---001 [Blackrock_4E5] tenant_db = 4E5 tenant_db_server = anderson.ldeo.columbia.edu

27 of 105

db_user = rudin_db_user2 db_pwd = rud1n2013$ weather_station_id = weather_central_park_nyc holiday_table = building_open_hour = 7 building_close_hour = 19 ; building floors to build model for tenant_floors = --results_db = 4E5 results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ electric_load_table = 4E5---------003BMSELEMETTEC---VAL001 save_tenant_data = 1 electric_load_table_total = 4E5---------000TPOFORELETEC001---001_Tenant_load electric_data_file = results_table_electric = 4E5---------000TPOFORELETEC001---001 score_table_electric = 4E5---------000TPOFORELETEC001---001_stats xval_results_table_electric = 4E5---------000TPOFORELETEC001---001_RBF_Params sign_prog = 012 train_covariate_filename_fmt_electric = \w+_electric_demand_tenant_%s_train_hour_(\d+)\.csv ; this flag currently indicates whether to issue alarms save_results = 1 alarms_table = 4E5---------000TPO---ALA---001

[Rudin_1BP] building_db = 1BP building_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ bms = ; building floor to build model for

28 of 105

building_floors = F02, F04, F06, F07, F09, F22, F27, F29, F33, F34, F35 ; floor quadrant to build model for floor_quadrants = CEA, CWE, CWE, CEA, CWE, CEA, CEA, CEA, CEA, CWE, CWE zones = sign_prog_space_temp = 001, 002, 003, 004, 005, 006, 007, 008, 009, 010, 011 holiday_table = building_open_hour = 7 building_close_hour = 19 weather_station_id = weather_central_park_nyc ; results database results_db = 1BP results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ # space temperature space_temp_tablename_format = 1BP---------004BMSHVATEMSPA---VAL001 results_table = 1BP---------000TPOFORTEMSPA001---001 prediction_derived_results_table = 1BP---------000TPOFORTEMSPA001---001_Derivative score_table = 1BP---------000TPOFORTEMSPA001---001_Stats xval_results_table = 1BP---------000TPOFORTEMSPA001---001_RBF_Params space_temp_deltas_table = 1BP---------000TPOFORTEMSPA001---001_Deltas # steam has_steam_supply = 1 steam_demand_table = 1BP---------004BMSSTEMET------VAL001 steam_data_file = %(data_sources_dir)s/MACH Energy - Usage Data_1BPP.txt results_table_steam = 1BP---------000TPOFORSTECON001---001 score_table_steam = 1BP---------000TPOFORSTECON001---001_Stats xval_results_table_steam = 1BP---------000TPOFORSTECON001---001_RBF_Params sign_prog_steam = # electric electric_load_table = 1BP---------004BMSELEMET------VAL001 electric_data_file = results_table_electric = 1BP---------000TPOFORELECON001---001 score_table_electric = 1BP---------000TPOFORELECON001---001_Stats xval_results_table_electric = 1BP---------000TPOFORELECON001---001_RBF_Params sign_prog_electric =

29 of 105

train_covariate_filename_fmt = \w+_%s_train_fl_%s_%s_hour_(\d+)\.csv train_covariate_filename_fmt_steam = \w+_steam_demand_%s_train_hour_(\d+)\.csv train_covariate_filename_fmt_electric = \w+_electric_demand_%s_train_hour_(\d+)\.csv feed_type = TPOSIF predict_occupancy = 1 occupancy_table = 1BP---------000SECCNTPEOBUI---VAL001 xval_results_table_occupancy = 1BP---------000TPOFORPEOBUI001---001_RBF_Params results_table_occupancy = 1BP---------000TPOFORPEOBUI001---001 score_table_occupancy = 1BP---------000TPOFORPEOBUI001---001_stats sign_prog_occupancy = train_covariate_filename_fmt_occupancy = \w+_occupancy_%s_train_hour_(\d+)\.csv

; this flag currently indicates whether to issue alarms save_results = 1 alarms_table = 1BP---------000TPO---ALA---001

[Rudin_WHI] building_db = WHI building_db_server = anderson.ldeo.columbia.edu bms = db_user = rudin_db_reader db_pwd = rudin_20!3$ ; building floor to build model for building_floors = F03, F06, F08, F10, F14, F15, F19, F19 zones = ; floor quadrant to build model for floor_quadrants = CNO, CWE, CSO, CEA, CEA, CNO, CSO, CWE sign_prog_space_temp = 001, 002, 003, 004, 005, 006, 007, 008 holiday_table = building_open_hour = 8 building_close_hour = 19 weather_station_id = weather_central_park_nyc

30 of 105

; results database results_db = WHI results_db_server = anderson.ldeo.columbia.edu ;;NEW AGB results_db_user = rudin_db_reader results_db_pwd = rudin_20!3$ # space temperature space_temp_tablename_format = WHI---------006BMSHVATEMSPA---VAL001 results_table = WHI---------000TPOHVATEMSPA001---001 prediction_derived_results_table = WHI---------000TPOHVATEMSPA001---001_Derivative score_table = WHI---------000TPOHVATEMSPA001---001_Stats xval_results_table = WHI---------000TPOHVATEMSPA001---001_RBF_Params space_temp_deltas_table = WHI---------000TPOHVATEMSPA001---001_Deltas # steam # 1 = yes; 0 = No has_steam_supply = 1 steam_data_file = %(data_sources_dir)s/MACH Energy - Usage Data_1WHI.txt results_table_steam = WHI---------000TPOFORSTECON001---001 score_table_steam = WHI---------000TPOFORSTECON001---001_Stats xval_results_table_steam = WHI---------000TPOFORSTECON001---001_RBF_Params steam_demand_table = WHI---------006BMSSTEMETTOT---VAL001 sign_prog_steam = 009 # electric electric_load_table = WHI---------006BMSELEMET------VAL001 electric_data_file = results_table_electric = WHI---------000TPOFORELECON001---001 score_table_electric = WHI---------000TPOFORELECON001---001_Stats xval_results_table_electric = WHI---------000TPOFORELECON001---001_RBF_Params sign_prog_electric = 010 ; fan table fan_table = WHI---------006BMSHVASFASAT---STA001 ; TODO covariates_table = ; this flag currently indicates whether to issue alarms save_results = 0 alarms_table = train_covariate_filename_fmt = \w+_%s_train_fl_%s_%s_hour_(\d+)\.csv train_covariate_filename_fmt_steam = \w+_steam_demand_%s_train_hour_(\d+)\.csv train_covariate_filename_fmt_electric = \w+_electric_demand_%s_train_hour_(\d+)\.csv

31 of 105

feed_type = TPOSIF predict_occupancy = 1 occupancy_table = WHI---------000SECCNTPEOBUI---VAL001 xval_results_table_occupancy = WHI---------000TPOFORPEOBUI001---001_RBF_Params score_table_occupancy = WHI---------000TPOFORPEOBUI001---001_Stats results_table_occupancy = WHI---------000TPOFORPEOBUI001---001 sign_prog_occupancy = 011 train_covariate_filename_fmt_occupancy = \w+_occupancy_%s_train_hour_(\d+)\.csv

results_table_startup = WHI---------000TPOOPTTEMUPT001---001 results_table_rampdown = WHI---------000TPOOPTTEMRDW001---001

[Rudin_641LE] building_db = 641 building_db_server = anderson.ldeo.columbia.edu bms = db_user = rudin_db_user2 db_pwd = rud1n2013$ ; building floor to build model for building_floors = F02, F06, F10, F15, F15, F28, F28 ; floor quadrant to build model for floor_quadrants = CSO, CWE, CWE, CNO, CWE, CSO, CNO zones = sign_prog_space_temp = 001, 002, 003, 004, 005, 006, 007

holiday_table = building_open_hour = 8 building_close_hour = 19 weather_station_id = weather_central_park_nyc ; results database results_db = 641 results_db_server = anderson.ldeo.columbia.edu

32 of 105

;;NEW AGB results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ # space temperature space_temp_tablename_format = 641---------005BMSHVATEMSPA---VAL001 results_table = 641---------000TPOHVATEMSPA001---001 prediction_derived_results_table = score_table = 641---------000TPOHVATEMSPA001---001_Stats xval_results_table = 641---------000TPOHVATEMSPA001---001_RBF_Params space_temp_deltas_table = # steam # 1 = yes; 0 = No has_steam_supply = 1 steam_data_file = %(data_sources_dir)s/MACH Energy - Usage Data_641.txt results_table_steam = 641---------000TPOFORSTECON001---001 score_table_steam = 641---------000TPOFORSTECON001---001_Stats xval_results_table_steam = 641---------000TPOFORSTECON001---001_RBF_Params steam_demand_table = 641---------005BMSSTEMET------VAL001 sign_prog_steam = 008 # electric electric_load_table = 641---------005BMSELEMET------VAL001 ;electric_load_table = Electric_Load_Filtered electric_data_file = results_table_electric = 641---------000TPOFORELECON001---001 score_table_electric = 641---------000TPOFORELECON001---001_Stats xval_results_table_electric = 641---------000TPOFORELECON001---001_RBF_Params sign_prog_electric = 009 ; fan table fan_table = 641---------005BMSHVARFARAT---STA001 ; TODO covariates_table = ; this flag currently indicates whether to issue alarms save_results = 0 alarms_table = train_covariate_filename_fmt = \w+_%s_train_fl_%s_%s_hour_(\d+)\.csv train_covariate_filename_fmt_steam = \w+_steam_demand_%s_train_hour_(\d+)\.csv train_covariate_filename_fmt_electric = \w+_electric_demand_%s_train_hour_(\d+)\.csv feed_type = TPOSIF

33 of 105

predict_occupancy = 1 occupancy_table = 641---------000SECCNTPEOBUI---VAL001 xval_results_table_occupancy = 641---------000TPOFORPEOBUI001---001_RBF_Params score_table_occupancy = 641---------000TPOFORPEOBUI001---001_Stats results_table_occupancy = 641---------000TPOFORPEOBUI001---001 sign_prog_occupancy = 010 train_covariate_filename_fmt_occupancy = \w+_occupancy_%s_train_hour_(\d+)\.csv

results_table_startup = 641---------000TPOOPTTEMUPT001---001 results_table_rampdown = 641---------000TPOOPTTEMRDW001---001 --- End of Config Script ---

34 of 105

5. Third-Party Software Requirements Here is the list of third-party software that is required to run TPO. Name

Version

License

Download or API at

Notes

Python

2.7.4

PSF License http://docs.python.or g/2/license.html

http://www.python .org/download/rel eases/2.7.4/

Setuptool s

06.c11

Python Software Foundation License

LIBSVM

Version 3.14

modified BSD license

https://pypi.pyth on.org/pypi/setup tools/0.6c11#down loads http://www.csie.n tu.edu.tw/~cjlin/ libsvm/

SciPy

Version 12.0

(modified) BSD

Install from MSI installer, add python directory, typically C:\Python27\, to PATH env variable This package includes easy-install package manager Install from exe installer See document on installation. It is already in the ML directory Install from exe installer

NumPy

1.6.2

(modified) BSD

Scikit Learn

0.14.1

BSD license (3 clause)

cfgparse

V01_02

matplotli b

1.2.1

pyodbc

3.0.6

Python Software Foundation License (http://docs.python.o rg/license.html) Python Software Foundation License derived (http://matplotlib.or g/users/license.html) MIT

pytz

2013b

MIT

Jetty

6.1.24

Microsoft MS SQL Server Java JRE

2008 R2

Apache License 2.0 with exemptions listed at http://svn.codehaus.o rg/jetty/jetty/branch es/jetty6.1/NOTICE.txt Microsoft EULA

1.6

OpOOp tiona l

X

Oracle Binary Code License Agreement

http://sourceforg e.net/projects/sc ipy/files/scipy/0 .12.0/scipy0.12.0-win32superpackpython2.7.exe/dow nload http://numpy.scip y.org/

Install from exe installer

http://sourceforg e.net/projects/sc ikit-learn/files/ http://cfgparse.s ourceforge.net/


http://matplotlib .org/


http://code.googl e.com/p/pyodbc/


http://pypi.pytho n.org/pypi/pytz/# downloads http://dist.codeh aus.org/jetty/

easy-install pytz2013b-py2.7.egg

http://www.oracle.com/t echnetwork/java/javase/ downloads/jre6download s-1902815.html

Install using the exe installer for JRE

Install from setup.py in install folder

Used by TPO-COM

35 of 105

MSSQL Native Client

2008 R2 & 2005 clients

http://www.micros oft.com/enus/download/detai ls.aspx?id=16978 & http://www.micros oft.com/enus/download/detai ls.aspx?id=15748

Microsoft Windows Operating System Microsoft .NET Framework Pandas

7 or Server 2008 R2

Microsoft EULA

4.0 or later

Microsoft EULA

0.12.0

BSD license (3 clause)

http://pandas.pyd ata.org/pandasdocs/stable/insta ll.html

Python dateutil

1.5

Simplified BSD

http://labix.org/ python-dateutil

Install both clients. The weather code uses the 2005 client

API Usage Name

Version

License

Download or API at

Weather Undergro und API

Latest

Terms of Service http://api.wunderground.com/weather/a pi/d/terms.html (use Developer Rate - 500 calls per day @ 10 /min max)

http://api.wunderground.com/we ather/api

36 of 105

6. Process Flow for Send and Receive Components TPOCOM is the set of TPO components that enable messaging and interactions with the SIF; TPOCOM is a pair of independent sub-systems referred to as the Sender and the Receiver. TPOCOM Sender reads TPO predictions generated by TPO analytics and sends/pushes them to the DI-BOSS SIF Server. In turn, the SIF Server receives building sensor data from the respective properties, formats this data into a SIF format, and then pushes the data to the TPOCOM Receiver. Provided below are the TPO process flow diagrams for the TPOCOM Sender and Receiver Modules. These diagrams display the internal functions performed supporting Send and Receive between TPO and the SIF server. The TPOCOM Sender is managed by the Task Runner component; the Task Runner performs the following ordered functions with the other respective TPO components: 1. Task Runner gets updated recommendations/predictions from the TPO database in which the TPO analytic processes have stored their most recent computed results (data points). 2. RowPoint conversion provides ~800 data points per hour to be used in data reporting visualizations. Task Runner interworks with the RowPoint Converter which works with the Point data structure by which prediction data points are formatted and assembled; these data points represent degrees of confidence reported in a graph for the various floors in a specific building. 3. Task Runner then requests TPOCOM to push/send the data to the SIF Server. 4. Also, the Task Runner maintains a heartbeat handshake protocol with the SIF Server once a minute. The TPOCOM Receiver relies on the Receiver Wssb2Impl component to respond to Web Service interrupt events and to process incoming data from the SIF. The Receiver calls the MSG Dispatcher to progress processing the incoming sensor point data received from the SIF; this processing entails: 1. conversion formatting of each data point 2. using the Connection Manager to access the respective TPO databases 3. writing to the TPO databases The TPOCOM Receiver makes use of a set of XML libraries to parse and process the incoming data from the SIF.

37 of 105

6.1 TPOCOM Instructions Codebase: TPO-COM comprises of java application jars and a few python utility scripts to help adding new buildings. The code is at trunk/TPOCOM in the SVN repository. Platform and Libraries: 1. Java 1.6 2. Python 2.7 3. XLRD 0.92 (required for config file generation. Not required on production system) 4. pyodbc 3.0.7 (required for config file generation. Not required on production system) 5. Jetty 6.1.24 BUILD: TPO-COM can be built using ant builds. TPO-COM sender can be built by running the following command in TPOCOMSender/: `ant`. The executable jar file can be found under TPOCOMSender/build/jar/ TPO-COM receiver service file *.aar can be built by doing running the follwing comand in TpoWSSB2_Server/:`ant`. The service *.aar file can be found under TpoWSSB2_Server/build/jar/ DEPLOYMENT: TPO-COM sender build generates an executable jar file. To start the sender just run the below command: ‘java -jar TPOCOMsender.jar TPOCOMSenderConfig.xml`. TPO-COM receiver service build generates a *.aar file. To start the receiver service copy the aar file under `$JETTY_HOME\webapps\axis2\WEB-INF\services` and run the below command from $JETTY_HOME directory: `java -jar start.jar`. Config file for the receiver should be specified in the following file: $JETTY_HOME\webapps\axis2\WEB-INF\jetty-env.xml SET UP FOR NEW BUILDINGS: The TPOCOM/setup directory has utility files that make adding a new building to TPOCOM easy: 1) input_db_setup.py This script takes the point list spreadsheet for a building and creates a new TPO database and the tables required to save the points being sent by SIF. The script provides a detailed help on all its arguments. 2) output_db_setup.py This script takes the point list spreadsheet for a building and creates a TPO database and the tables required to save the points to be generated by TPO. In addition it also creates the tracker tables required to track the points sent to SIF. The script provides a detailed help on all its arguments.

38 of 105

3) receiver_config_generate.py This script generates the configuration file for TPOCOM receiver. It takes points list, TPO database server details as input. It can generate a new configuration file or just add a new building to the existing receiver configuration file. The script provides a detailed help on all its arguments. 4) sender_config_generate.py This script generates the configuration file for TPOCOM sender. It takes points list, TPO database server, SIF endpoint, TPO endpoint, TPOCOM settings as input. It can generate a new configuration file or just add a new building to the existing sender configuration file. The script provides a detailed help on all its arguments. 6.2 Recommended Instructions 1) It is recommended to always start TPOCOM receiver first and then TPOCOM sender. 2) Selex owns the following packages that are used by TPOCOM: TpoWSSB2_Client, TpoWSSB2_Server and XmlTool. Jetty server 6.1.24 3) If Selex sends updated code for TpoWSSB2_Client or XmlTool, just replace old versions in svn. But if they send updated version of TpoWSSB2_Server make sure to check it in svn replacing the current version but keep your implementation of the onMessageAndResponse method in Wssb2Impl.java present in package TpoWSSB2_Server. 4) Wssb2Impl.java creates static objects of ConnectionManager, MsgDispatcher and Configuration. This is done in order to avoid creating a new instance of these objects when we receive messages. The Jetty server creates a new instance of Wssb2Impl class for every new message it receives 5) TPOCOM runs its own scheduler. But you need to set up .bat files to start the receiver and sender when the machine restarts. 6) The receiver and the sender can be gracefully shutdown by using Ctrl + c

39 of 105

40 of 105

7. General Installation Instructions On the Application Server Copy the TPO directory to where you would like to install it. We suggest the C drive if possible. Refer to the 3rd Party Software Table above for proper versions. The install CD has a directory under the TPO directory TPO\Install\TPO-libraries with these libraries ready to install. 1. Install the Python Environment. Install from the MSI installer A. Install Python. Install from MSI installer, add python directory, typically C:\Python27\, to the PATH env variable B. Install Setuptools into Python . This package includes easy-install package manager. Install from exe installer. C. Install NumPy into Python. Install from exe installer D. Install SciPy into Python. Install from exe installer E. Install Scikit Learn into Python. Install from exe installer F. Install cfgparse into Python. Install from in install folder by calling python setup.py G. (Optional) Install matplotlibinto Python. Install from exe installer H. Install pyodbc into Python. Install from exe installer I. Install pytz into Python. Install using easy-install pytz-2013bpy2.7.egg 2. Install MSSQL Native Client (both 2008 R2 & 2005 clients). The links are http://www.microsoft.com/en-us/download/details.aspx?id=16978 & http://www.microsoft.com/en-us/download/details.aspx?id=15748 3. Get Weather Underground API Key. Go to http://api.wunderground.com/weather/api 4. Configure config.ini under the TPO directory. See manuals above for how to configure this file. 5. Set up the scheduled tasks. In TPO\Install\tasks are XML tasks that can be imported into Microsoft Task Scheduler. For each task, set the appropriate user to run that task as. Make sure to change the path to python if it is not installed in C:\python27\ in these tasks. 6. Build TPO-COM according to the manual for it above. (TPO-COM can run from the Application Server or the DB Server.) Configure TPO-COM for the buildings of interest.

41 of 105

On the Web Server Install the TPOWEB directory and configure the web server according to the manual for it above. On the DB server There is one database per building. There is also the Weather database, and the TPOCOM internal database. There is a database backup file for TPOWEB provided in its directory. Example sql scripts are provided in TPO\Install\db-scripts to help establish the databases, tables, views, db functions and DB users for the Weather and TPOCOM databases. To establish the tables a coordinated process is done to configure TPOCOM using its config files, the config.ini file in TPO and the database. Refer to the manuals for systems above. This process is not automated and requires modification of these example scripts as well. In addition, these scripts do not provide data so establish the historical data and configuring TPOCOM to then fill the tables in real time has to be done. There are some smaller tables, like the Floor_Mapping and Quadrant_Mapping tables that can be filled with knowledge of the specifics of the building by hand. In addition, a minimal skeleton script and an initial interface to help generate some initial tables for a new building is provided. This interface generates a new skeleton script. There are four example scripts provided. 1. 345-init.sql to establish the 345 database 2. 560-init.sql to establish the 560 database 3. Weather-init.sql to establish the Weather database 4. TPOCOM-init to establish the TPOCOM database One should delete the unnecessary non TPO system users in the scripts and rename, add, or delete non relevant tables based on specifics of the building. Someone familiar with SQL is best to do this work.

42 of 105

8. Electric Tenant Load Predictor Component Instructions Programmer Instructions Synopsis: > python predict_electric_usage_tenant.py [ ] [options] Options: --version show program's version number and exit -h, --help show this help message and exit --cfghelp Show configuration file help and exit. -k LIST, --keys=LIST Comma separated list of configuration keys. --cfgfiles=LIST Comma separated list of configuration files. Standard Options: --running_at=RUNNING_AT determines whether code is running at customer site or at ccls See also 'running_at' option in configuration file help. --python_prog=PYTHON_PROG location of python interpreter See also 'python_prog' option in configuration file help. --perl_prog=PERL_PROG location of perl interpreter See also 'perl_prog' option in configuration file help. --log_level=LOG_LEVEL top level message threshold See also 'log_level' option in configuration file help. --log_console=LOG_CONSOLE set true to add stderr as a log device See also 'log_console' option in configuration file help. --log_console_level=LOG_CONSOLE_LEVEL severity threshold for console logging See also 'log_console_level' option in configuration file help. --log_console_msg_fmt=LOG_CONSOLE_MSG_FMT message format for console See also

43 of 105

'log_console_msg_fmt' option in configuration file help. --log_file=LOG_FILE set true to add a rotating file as a log device See also 'log_file' option in configuration file help. --log_file_level=LOG_FILE_LEVEL severity threshold for file logging See also 'log_file_level' option in configuration file help. --log_file_msg_fmt=LOG_FILE_MSG_FMT message format for log file See also 'log_file_msg_fmt' option in configuration file help. --log_file_dir=LOG_FILE_DIR dir for log file See also 'log_file_dir' option in configuration file help. --log_file_mode=LOG_FILE_MODE mode for log file, w or a See also 'log_file_mode' option in configuration file help. --log_file_maxbytes=LOG_FILE_MAXBYTES max size for log file before rotation See also 'log_file_maxbytes' option in configuration file help. --log_file_backup_count=LOG_FILE_BACKUP_COUNT if non-zero, number of old logs to keep See also 'log_file_backup_count' option in configuration file help. --base_dir=BASE_DIR dir where everything starts from See also 'base_dir' option in configuration file help. --temp_dir=TEMP_DIR dir for temp files, e.g. bulk insert See also 'temp_dir' option in configuration file help. --data_dir=DATA_DIR static data and destination for models See also 'data_dir' option in configuration file help. --data_sources_dir=DATA_SOURCES_DIR location for data sources See also 'data_sources_dir'

44 of 105

option in configuration file help. --control_dir=CONTROL_DIR location for control scripts See also 'control_dir' option in configuration file help. --test=TEST if non-zero, run in module-specific test mode See also 'test' option in configuration file help. --debug=DEBUG if non-zero, print more debugging statements See also 'debug' option in configuration file help. --logger_configured=LOGGER_CONFIGURED if non-zero, calling app has already set up logger See also 'logger_configured' option in configuration file help. --db_driver=DB_DRIVER database driver See also 'db_driver' option in configuration file help. --forecast_granularity=FORECAST_GRANULARITY Interval in minutes between consecutive input/forecasted data points See also 'forecast_granularity' option in configuration file help. --forecast_length=FORECAST_LENGTH forecast length in number of hours See also 'forecast_length' option in configuration file help. --building_ids=BUILDING_IDS comma separated building ids for buildings to process See also 'building_ids' option in configuration file help. --tenant_ids=TENANT_IDS comma separated tenant ids for tenants to process See also 'tenant_ids' option in configuration file help. --training_radius=TRAINING_RADIUS number of days of recent data to use for training See also 'training_radius' option in configuration file help. --use_weather_forecast=USE_WEATHER_FORECAST

45 of 105

switch to turn off/on weather forecast usage See also 'use_weather_forecast' option in configuration file help. --svm_dir=SVM_DIR directory for Support Vector Machine programs See also 'svm_dir' option in configuration file help. --svm_uci=SVM_UCI Support Vector Machine format conversion program See also 'svm_uci' option in configuration file help. --svm_scale=SVM_SCALE Support Vector Machine data normalization program See also 'svm_scale' option in configuration file help. --svm_predict=SVM_PREDICT Support Vector Machine prediction program See also 'svm_predict' option in configuration file help. --svm_train=SVM_TRAIN Support Vector Machine training program See also 'svm_train' option in configuration file help. --svm_weight=SVM_WEIGHT Support Vector Machine weight extraction program See also 'svm_weight' option in configuration file help. Example: To generate predictions as of 7/16/2013 6 pm, > python predict_electric_usage_tenant.py 2013 7 16 18 0 Description: Predicts tenant electric load for the next 24 hours starting from the as-of-date for all buildings specified in the configuration file. If no date is specified, the predictions are generated as of the current system time. Predictions can’t be generated as of a future date. Predictions have 15 minute granularity and are generated using past tenant electric load observations as well as observed and forecasted weather data. predict_electric_usage.py has been designed to be run once every hour

Installation Instructions The predictor expects 13 months of past tenant electric load observations and weather data, both observed and forecasted, to be available. At least 24 hours of forecasted weather data is required beginning model generation time.

46 of 105

The predictor uses the output of the electric model optimizer, which must be set up to run once a day. Location: Rudin/electric Synopsis: > python cross_validate_tenant.py Description: Optimizes tenant electric load model parameters for all tenants of the buildings as specified in the configuration file and saves them to the database. This module uses the feature set files created by the corresponding predictor module. It also cleans up old feature set files. In addition, error scores are computed on the output of the predictor by the corresponding evaluator/scoring module, which can be setup as a scheduled task to be run once a day. Location: Rudin/common_rudin Synopsis: > python score_prediction_electric_tenant.py Description: Computes the Root Mean Squared Error (RMSE), Mean Absolute Error (MAE) and Mean Absolute Percentage Error (MAPE) for tenant electric load predictions from the last 30 days for tenants of all buildings as specified in the common configuration file and saves the results to the database. If error scores already exist for a given day and building, they are updated/overwritten. Location of the files, where it should be installed? Rudin/electric, Rudin/common_rudin

Once installed, what configuration script needs to be run? None

Configuration Instructions This module reads the user-configurable settings from the common configuration file. [] tenant_db = 345 tenant_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ weather_station_id = weather_central_park_nyc building_open_hour = 7 building_close_hour = 19

47 of 105

; building floors to build model for tenant_floors = F02, F04 results_db = 345 results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ electric_load_table = 345---------001EMSSMAMET------40120001 electric_data_file = %(data_sources_dir)s/KPMG.txt results_table_electric = 345---------000TPOFORELECON001---001_KPMG score_table_electric = 345---------000TPOFORELECON001---001_KPMG_stats xval_results_table_electric = 345---------000TPOFORELECON001---001_KPMG_RBF_Params train_covariate_filename_fmt_electric = \w+_electric_demand_tenant_%s_train_hour_(\d+)\.csv On a daily basis, is there daily configuration that needs to be run? No

48 of 105

9. Electric Predictor Component Instructions Programmer Instructions Synopsis: > python predict_electric_usage.py [ ] [options] Options: --version show program's version number and exit -h, --help show this help message and exit --cfghelp Show configuration file help and exit. -k LIST, --keys=LIST Comma separated list of configuration keys. --cfgfiles=LIST Comma separated list of configuration files. Standard Options: --running_at=RUNNING_AT determines whether code is running at customer site or at ccls See also 'running_at' option in configuration file help. --python_prog=PYTHON_PROG location of python interpreter See also 'python_prog' option in configuration file help. --perl_prog=PERL_PROG location of perl interpreter See also 'perl_prog' option in configuration file help. --log_level=LOG_LEVEL top level message threshold See also 'log_level' option in configuration file help. --log_console=LOG_CONSOLE set true to add stderr as a log device See also 'log_console' option in configuration file help. --log_console_level=LOG_CONSOLE_LEVEL severity threshold for console logging See also 'log_console_level' option in configuration file help. --log_console_msg_fmt=LOG_CONSOLE_MSG_FMT message format for console See also 'log_console_msg_fmt' option in configuration file

49 of 105

help. --log_file=LOG_FILE set true to add a rotating file as a log device See also 'log_file' option in configuration file help. --log_file_level=LOG_FILE_LEVEL severity threshold for file logging See also 'log_file_level' option in configuration file help. --log_file_msg_fmt=LOG_FILE_MSG_FMT message format for log file See also 'log_file_msg_fmt' option in configuration file help. --log_file_dir=LOG_FILE_DIR dir for log file See also 'log_file_dir' option in configuration file help. --log_file_mode=LOG_FILE_MODE mode for log file, w or a See also 'log_file_mode' option in configuration file help. --log_file_maxbytes=LOG_FILE_MAXBYTES max size for log file before rotation See also 'log_file_maxbytes' option in configuration file help. --log_file_backup_count=LOG_FILE_BACKUP_COUNT if non-zero, number of old logs to keep See also 'log_file_backup_count' option in configuration file help. --base_dir=BASE_DIR dir where everything starts from See also 'base_dir' option in configuration file help. --temp_dir=TEMP_DIR dir for temp files, e.g. bulk insert See also 'temp_dir' option in configuration file help. --data_dir=DATA_DIR static data and destination for models See also 'data_dir' option in configuration file help. --data_sources_dir=DATA_SOURCES_DIR location for data sources See also 'data_sources_dir' option in configuration file help.

50 of 105

--control_dir=CONTROL_DIR location for control scripts See also 'control_dir' option in configuration file help. --test=TEST if non-zero, run in module-specific test mode See also 'test' option in configuration file help. --debug=DEBUG if non-zero, print more debugging statements See also 'debug' option in configuration file help. --logger_configured=LOGGER_CONFIGURED if non-zero, calling app has already set up logger See also 'logger_configured' option in configuration file help. --db_driver=DB_DRIVER database driver See also 'db_driver' option in configuration file help. --forecast_granularity=FORECAST_GRANULARITY Interval in minutes between consecutive input/forecasted data points See also 'forecast_granularity' option in configuration file help. --forecast_length=FORECAST_LENGTH forecast length in number of hours See also 'forecast_length' option in configuration file help. --building_ids=BUILDING_IDS comma separated building ids for buildings to process See also 'building_ids' option in configuration file help. --tenant_ids=TENANT_IDS comma separated tenant ids for tenants to process See also 'tenant_ids' option in configuration file help. --training_radius=TRAINING_RADIUS number of days of recent data to use for training See also 'training_radius' option in configuration file help. --use_weather_forecast=USE_WEATHER_FORECAST switch to turn off/on weather forecast usage See also

51 of 105

'use_weather_forecast' option in configuration file help. --svm_dir=SVM_DIR directory for Support Vector Machine programs See also 'svm_dir' option in configuration file help. --svm_uci=SVM_UCI Support Vector Machine format conversion program See also 'svm_uci' option in configuration file help. --svm_scale=SVM_SCALE Support Vector Machine data normalization program See also 'svm_scale' option in configuration file help. --svm_predict=SVM_PREDICT Support Vector Machine prediction program See also 'svm_predict' option in configuration file help. --svm_train=SVM_TRAIN Support Vector Machine training program See also 'svm_train' option in configuration file help. --svm_weight=SVM_WEIGHT Support Vector Machine weight extraction program See also 'svm_weight' option in configuration file help. Example: To generate predictions as of 7/16/2013 6 pm, > python predict_electric_usage.py 2013 7 16 18 0 Description: Predicts electric load for the next 24 hours starting from the as-of-date for all buildings specified in the configuration file. If no date is specified, the predictions are generated as of the current system time. Predictions can’t be generated as of a future date. Predictions have 15 minute granularity and are generated using past electric load observations of the building as well as observed and forecasted weather data. predict_electric_usage.py has been designed to be run once every hour

Installation Instructions The predictor expects 13 months of past electric load observations and weather data, both observed and forecasted, to be available. At least 24 hours of forecasted weather data is required beginning model generation time. The predictor uses the output of the electric model optimizer, which must be set up to run once a day.

52 of 105

Location: Rudin/electric Synopsis: > python cross_validate.py Description: Optimizes electric model parameters for the buildings specified in the configuration file and saves them to the database. This module uses the feature set files created by the corresponding predictor module. It also cleans up old feature set files. In addition, error scores are computed on the output of the predictor by the corresponding evaluator/scoring module, which can be setup as a scheduled task to be run once a day. Location: Rudin/common_rudin Synopsis: > python score_prediction_steam_electric.py Description: Computes the Root Mean Squared Error (RMSE), Mean Absolute Error (MAE) and Mean Absolute Percentage Error (MAPE) for electric load predictions from the last 30 days for all the buildings specified in the common configuration file and saves the results to the database. If error scores already exist for a given day and building, they are updated/overwritten. Location of the files, where it should be installed? Rudin/electric, Rudin/common_rudin


Configuration Instructions This module reads the user-configurable settings from the common configuration file. [] building_db = 345 building_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ bms = Johnson Controls ; building floor to build model for building_floors = F02, F04, F04, F05, F13, F18, F20, F24, F32, F38, F40 ; floor quadrant to build model for floor_quadrants = CNW, CNW, CSE, CSE, CSW, CSE, CSW, CSE, CNW, CNW, CNE

53 of 105

holiday_table = building_open_hour = 7 building_close_hour = 19 weather_station_id = weather_central_park_nyc ; results database results_db = 345 results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ electric_load_table = 345---------001BMSELEMET------VAL001 electric_data_file = %(data_sources_dir)s/MACH Energy - Electric Usage Data.txt results_table_electric = 345---------000TPOFORELECON001---001 score_table_electric = 345---------000TPOFORELECON001---001_Stats xval_results_table_electric = 345---------000TPOFORELECON001---001_RBF_Params train_covariate_filename_fmt_electric = \w+_electric_demand_%s_train_hour_(\d+)\.csv On a daily basis, is there daily configuration that needs to be run? No

54 of 105

10. Space Temperature Predictor Component Instructions Programmer Instructions Synopsis: > python predict_space_temp.py [ ] [options] predict space temperature in a given quadrant of a given floor based on past observed load and other covariates Options: --version show program's version number and exit -h, --help show this help message and exit --cfghelp Show configuration file help and exit. -k LIST, --keys=LIST Comma separated list of configuration keys. --cfgfiles=LIST Comma separated list of configuration files. Standard Options: --running_at=RUNNING_AT determines whether code is running at customer site or at ccls See also 'running_at' option in configuration file help. --python_prog=PYTHON_PROG location of python interpreter See also 'python_prog' option in configuration file help. --perl_prog=PERL_PROG location of perl interpreter See also 'perl_prog' option in configuration file help. --log_level=LOG_LEVEL top level message threshold See also 'log_level' option in configuration file help. --log_console=LOG_CONSOLE set true to add stderr as a log device See also 'log_console' option in configuration file help. --log_console_level=LOG_CONSOLE_LEVEL severity threshold for console logging See also 'log_console_level' option in configuration file help. --log_console_msg_fmt=LOG_CONSOLE_MSG_FMT message format for console See also 55 of 105


56 of 105


57 of 105

switch to turn off/on weather forecast usage See also 'use_weather_forecast' option in configuration file help. --svm_dir=SVM_DIR directory for Support Vector Machine programs See also 'svm_dir' option in configuration file help. --svm_uci=SVM_UCI Support Vector Machine format conversion program See also 'svm_uci' option in configuration file help. --svm_scale=SVM_SCALE Support Vector Machine data normalization program See also 'svm_scale' option in configuration file help. --svm_predict=SVM_PREDICT Support Vector Machine prediction program See also 'svm_predict' option in configuration file help. --svm_train=SVM_TRAIN Support Vector Machine training program See also 'svm_train' option in configuration file help. --svm_weight=SVM_WEIGHT Support Vector Machine weight extraction program See also 'svm_weight' option in configuration file help. Example: To generate predictions as of 7/16/2013 6 pm, > python predict_space_temp.py 2013 7 16 18 0 Description: Predicts control zone space temperature for the next 24 hours starting from the asof-date for control zones of all the buildings specified in the configuration file. If no date is specified, the predictions are generated as of the current system time. Predictions can’t be generated as of a future date. Predictions have 15 minute granularity and are generated using past space temperature observations of the control zone as well as observed and forecasted weather data. predict_space_temp.py has been designed to be run once every hour

Installation Instructions The predictor expects 13 months of past space temperature observations and weather data, both observed and forecasted, to be present. At least 24 hours of forecasted weather data is required beginning model generation time.

58 of 105

The predictor uses the output of the space temperature model optimizer which must be set up to run once a day. Location: Rudin/common_rudin Synopsis: > python cross_validate.py Description: Optimizes control zone space temperature model parameters for control zones of all the buildings as specified in the configuration file and saves them to the database. This module uses the feature set files created by the corresponding predictor module. It also cleans up old feature set files. In addition, the output of the predictor is scored by the corresponding evaluator module which can be setup as a scheduled task to be run once a day. Location: Rudin/common_rudin Synopsis: > python score_prediction_space_temp.py Description: Computes the Root Mean Squared Error (RMSE), Mean Absolute Error (MAE) and Mean Absolute Percentage Error (MAPE) for control zone space temperature predictions for the last 30 days for all the buildings specified in the common configuration file and saves the results to the database. If scores already exists for a given day, they are updated/overwritten. Location of the files, where it should be installed? Rudin/space_temp, Rudin/common_rudin


Configuration Instructions This module reads the user-configurable settings from the common configuration file. [] building_db = 345 building_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ bms = Johnson Controls ; building floor to build model for

59 of 105

building_floors = F02, F04, F04, F05, F13, F18, F20, F24, F32, F38, F40 ; floor quadrant to build model for floor_quadrants = CNW, CNW, CSE, CSE, CSW, CSE, CSW, CSE, CNW, CNW, CNE holiday_table = building_open_hour = 7 building_close_hour = 19 weather_station_id = weather_central_park_nyc ; results database results_db = 345 results_db_server = anderson.ldeo.columbia.edu ;;NEW AGB results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ # space temperature space_temp_tablename_format = 345---------001BMSHVATEMSPA---VAL001 results_table = 345---------000TPOFORTEMSPA001---001 prediction_derived_results_table = 345---------000TPOFORTEMSPA001---001_Derivative score_table = 345---------000TPOFORTEMSPA001---001_Stats xval_results_table = 345---------000TPOFORTEMSPA001---001_RBF_Params space_temp_deltas_table = 345---------000TPOFORTEMSPA001---001_Deltas train_covariate_filename_fmt = \w+_%s_train_fl_%s_%s_hour_(\d+)\.csv On a daily basis, is there daily configuration that needs to be run? No

60 of 105

11. Steam Usage Predictor Component Instructions Programmer Instructions Synopsis: > python predict_steam_usage.py [ ] [options] Options: --version show program's version number and exit -h, --help show this help message and exit --cfghelp Show configuration file help and exit. -k LIST, --keys=LIST Comma separated list of configuration keys. --cfgfiles=LIST Comma separated list of configuration files. Standard Options: --running_at=RUNNING_AT determines whether code is running at customer site or at ccls See also 'running_at' option in configuration file help. --python_prog=PYTHON_PROG location of python interpreter See also 'python_prog' option in configuration file help. --perl_prog=PERL_PROG location of perl interpreter See also 'perl_prog' option in configuration file help. --log_level=LOG_LEVEL top level message threshold See also 'log_level' option in configuration file help. --log_console=LOG_CONSOLE set true to add stderr as a log device See also 'log_console' option in configuration file help. --log_console_level=LOG_CONSOLE_LEVEL severity threshold for console logging See also 'log_console_level' option in configuration file help. --log_console_msg_fmt=LOG_CONSOLE_MSG_FMT message format for console See also

61 of 105


62 of 105


63 of 105

switch to turn off/on weather forecast usage See also 'use_weather_forecast' option in configuration file help. --svm_dir=SVM_DIR directory for Support Vector Machine programs See also 'svm_dir' option in configuration file help. --svm_uci=SVM_UCI Support Vector Machine format conversion program See also 'svm_uci' option in configuration file help. --svm_scale=SVM_SCALE Support Vector Machine data normalization program See also 'svm_scale' option in configuration file help. --svm_predict=SVM_PREDICT Support Vector Machine prediction program See also 'svm_predict' option in configuration file help. --svm_train=SVM_TRAIN Support Vector Machine training program See also 'svm_train' option in configuration file help. --svm_weight=SVM_WEIGHT Support Vector Machine weight extraction program See also 'svm_weight' option in configuration file help. Example: To generate predictions as of 7/16/2013 6 pm, > python predict_steam_usage.py 2013 7 16 18 0 Description: Predicts building steam usage for the next 24 hours starting from the as-of-date for all buildings specified in the configuration file. If no date is specified, the predictions are generated as of the current system time. Predictions can’t be generated as of a future date. Predictions have 15 minute granularity and are generated using past steam usage observations of the building as well as observed and forecasted weather data. predict_steam_usage.py has been designed to be run once every hour

Installation Instructions The predictor expects 25 months of past steam usage observations and weather data, both observed and forecasted, to be available. At least 24 hours of forecasted weather data is required beginning model generation time.

64 of 105

The predictor uses the output of the steam model optimizer, which must be set up to run once a day. Location: Rudin/steam Synopsis: > python cross_validate.py Description: Optimizes steam model parameters for the buildings specified in the configuration file and save them to the database. This module uses the feature set files created by the corresponding predictor module. It also cleans up old feature set files. In addition, error scores are computed on the output of the predictor by the corresponding evaluator/scoring module, which can be setup as a scheduled task to be run once a day. Location: Rudin/common_rudin Synopsis: > python score_prediction_steam_electric.py Description: Computes the Root Mean Squared Error (RMSE), Mean Absolute Error (MAE) and Mean Absolute Percentage Error (MAPE) for steam usage predictions from the last 30 days for all the buildings specified in the common configuration file and saves the results to the database. If error scores already exist for a given day and building, they are updated/overwritten. Location of the files, where it should be installed? Rudin/steam, Rudin/common_rudin


Configuration Instructions This module reads the user-configurable settings from the common configuration file. [] building_db = 345 building_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ bms = Johnson Controls ; building floor to build model for building_floors = F02, F04, F04, F05, F13, F18, F20, F24, F32, F38, F40

65 of 105

; floor quadrant to build model for floor_quadrants = CNW, CNW, CSE, CSE, CSW, CSE, CSW, CSE, CNW, CNW, CNE holiday_table = building_open_hour = 7 building_close_hour = 19 weather_station_id = weather_central_park_nyc ; results database results_db = 345 results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ has_steam_supply = 1 steam_data_file = %(data_sources_dir)s/Steam Mlbs 345 Park.txt results_table_steam = 345---------000TPOFORSTECON001---001 score_table_steam = 345---------000TPOFORSTECON001---001_Stats xval_results_table_steam = 345---------000TPOFORSTECON001---001_RBF_Params train_covariate_filename_fmt_steam = \w+_steam_demand_%s_train_hour_(\d+)\.csv On a daily basis, is there daily configuration that needs to be run? No

66 of 105

12. Weather Component Instructions Programmer Instructions Two tasks need to be set up in the task manager Name Task Description WXOUPDATE Weather Observation Update WXFUPDATE Weather Forecast Update

Frequency 1/hr 1/hr

For WXOUPDATE task, the action should be python weather_history.py and also started in the Weather\python subdirectory under the TPO install directory. For the WXFUPDATE task, the action should be python hourly_forecast.py and started in the Weather\python subdirectory under the TPO install directory. The weather observation script is run starting 12:15AM every hour. The update weather forecast script is run starting 12:20AM every hour Installation Instructions The Python scripts and SQL scripts reside in the Weather subdirectory under the TPO home directory. The SQL scripts are in the sqlserver subdirectory. Of note, there are sql scripts in that directory to create the weather observations and the weather forecast tables if need be. Weather observations and forecasts go into a database called Weather on the TPO database server. Other SQL scripts in that directory are called by the python scripts to ensure that unknown or missing values are always is represented by -9999 No initiation or configuration scripts need to be run to install and ready the weather component other than the create_obs_weather.sql script to create the observation table and the create_raw_weather.sql script to create the forecast table in Microsoft SQL Server Management Studio if those tables are not already in the Weather database. The weather history database can be established with prior observations by manually running the observation script, weather_history.py, with, for example, the argument --start=2011-01-01 to start the history from the beginning of 2011. Any arguments passed in the command line will override the settings in the config.ini file. It should be noted that the Weather Underground API only allows 500 calls per day so weather_history.py may need to be invoked over several days if multiple years of observation data is required. Call it with successively earlier start dates to complete the necessary history. TPO currently requires 26 months of past observation data, so a single call to the

67 of 105

script should be sufficient to bring over all the required observation history. One could also temporarily modify the config.ini file to do the same.

Figure 2: Command line arguments to the weather history update script. Use --start YYYY-MM-DD to initialize weather history in the weather observations table Configuration Instructions The configuration section of the config.ini file for the observation data consists of: ;This section uses the name the weather station used KNYC (central park) [History_NY_KNYC] driver = {SQL Native Client} server = 192.168.99.12 ;server = anderson.ldeo.columbia.edu database = Weather UID = weather PWD = rudin_20!3$ table = Observations_History ;get your own key from http://api.wunderground.com/api/ 68 of 105

api_key = xxxxxxxxxxxxxxxx ;Delta in days to truncate before adding. Normally this is 0 delta = 0 ;start populating for the last entry datetime if latest is used. ;If a date is specified, will start from that date. ;A start date is like 2011-01-01 # yyyy-mm-dds start = latest ;New York Central Park, just KNYC also works as well as NY/KNYC location = NY/KNYC ;Hunter College weather station ;This is how a personal weather station like Hunter College ;is specified in the Weather Underground API ;location = pws:KNYNEWYO45 #New York Hunter College The configuration section of the config.ini file for the forecast data consists of: [Forecast_NY_KNYC] driver = {SQL Native Client} server = 192.168.99.12 database = Weather UID = weather PWD = rudin_20!3$ table = Hourly_Forecast ;get your own key from http://api.wunderground.com/api/ api_key = xxxxxxxxxxxxxxxx ;New York Central Park, just KNYC also works as well as NY/KNYC location = NY/KNYC ;Hunter College weather station ;location = pws:KNYNEWYO45 #New York Hunter Note that using location = NY/New_York is not a good idea since Weather Underground will assign a station to represent NYC and it will not necessarily be Central Park. Both of these uses a Weather Underground API key that you can get from http://www.wunderground.com/weather/api/. Please do not use our development API key because usage will be counted against our key. You can get the free developer version since the number of calls to the API for Di-Boss installation will be under the developer limit. For the Rudin installation at Avenue of Americas, the deployment key used is 1addc4d75f3b92bc

69 of 105

13. Startup and Ramp Down Recommendation Space Temperature Trajectory Component Instructions Programmer Instructions Synopsis: > python predict_startup_rampdown.py [] Recommends startup and rampdown time for the upcoming day Synopsis: > python now_cast.py [] Predicts interior space temperature trajectory for the floors Options:

specifies the building to recommend for (optional)

Installation Instructions

The recommender expects at least 1 month of past steam usage, electric load, interior space temperature, occupancy, fan status and weather data observations to be available. At least 24 hours of forecasted data on all the aforementioned point names except for the fan status is also required. The predictor uses the output of the steam, electric and occupancy and weather predictor, which must be set up to run hourly. In addition, feedback from building operators and engineers should be provided through some mean. Location: Rudin/startup_rampdown Location: Rudin/spaceTemperature_trajectory

70 of 105

Configuration Instructions

This module reads the user-configurable settings from the common configuration file. In addition to the options mentioned in the previous sections, the followings should be provided in each building section name. [] results_table_startup = 345---------000TPOOPTTEMUPT001---001 results_table_rampdown = 345---------000TPOOPTTEMRDW001---001 ; fan table fan_table = 345---------001BMSHVAFANLCP---VAL001

71 of 105

14. Topic Discussion on Preheating Recommendations Preheating Recommendations within the Columbia University Total Property Optimizer (TPO) for Winter Operations of High-Rise Office Buildings New York City’s steam system supplies 27 billion pounds a year to heat, cool, and power Manhattan buildings. Many commercial buildings use steam to meet their space temperature requirements. Contractually, landlords must maintain a space temperature within a specific range during the workday. As a result, peak demand for steam in New York occurs during the colder months of the year. The provider of these steam services, Con Edison, charges an additional onpeak fee for steam demanded between the hours of 6 and 11 in the morning from December to March, as the workday begins. This on-peak-fee is equal to $1,629 times the maximum rate of steam, measured in million pounds per hour (Mlb\hr), demanded during on-peak hours within a billing cycle between December and March. This rate is the most expensive within Con Edison’s billing structure, by far. To minimize this charge during building start-up building managers attempt to heat the building using steam before 6 am. By storing energy generated by steam before 6 am, they “preheat” the building using an effective Hydro-Battery. That is they pump heated water into the riser circulation system of the building before 6am and return the hot water to the HVAC system after 6am at little additional cost. Specifically, if the maximum rate of steam demanded before 6 am is greater than the maximum rate demanded between 6 and 11 am, the building has been “preheated”, and the cost of that off-peak-fee steam is 100 times cheaper. An example of preheat during building start-up is shown below in figure 1. These graphs come from building data supplied by 345 Park Avenue, a building that has shared its real time data with Columbia University. Typically, building managers at 345 Park preheat each day during the on-peak winter heating months. The two dates in each plot have similar weather based on the their heat indexes. In each plot, a spike occurs each day before 7 am. To store heat, building managers turn on water pumps to fill the vertical riser pipes with hot water. This sudden increase in demand for heat results in a steam demand spike. To release the stored heat, building managers turn on the HVAC fans that then circulate air heated by the hot water throughout the building. On preheat days, steam demand spikes occur before 6 am. One can observe that preheat does not always result in a greater daily steam consumption or spike in steam usage. Given these temperature and peak demand penalties, building managers do not yet know the optimal method to reduce steam demand and steam costs during these on-peak months. The TPO preheat objective, therefore, is to compute the optimal means of heating the building that reduces steam demand and minimizes cost and recommend that the day before to building operators.

72 of 105

Steam'Demand'Comparison'of'a'Preheat'Vs'No' Preheat'Day'

Steam'Demand'Comparison'of'a'Preheat'Vs'No' Preheat'Day'

No Preheat

MLB/HR'

MLB/HR'

No Penalty Preheat

No Preheat

Preheat

Hour'of'the'day'

TPO Machine Learning Recommends Preheatme Preheat

Preheat

Hour'of'the'day'

Matching “Like –Weather –Days” from the Winters of 2012 (before TPO) and 2013 (a er TPO), we found 23 Like–Days that had Preheat versus No Preheat. The Costs of these days allowed us to es mate the Benefits of Preheat Forecas ng from TPO.

Figure 1: Preheat (red) vs no preheat (blue) on similar days during the period of December 2011 to March 2013. Note the spike in steam demand during each morning. In the case of preheat, this spike is before peak hours of 6-11am. Preheat does not guarantee a larger spike in steam. TPO uses as Support Vector Machine learning covariates data going back as far as January 2012, which includes weather, predicted weather, internal temperature recordings, and water pump and fan indicators from the Building Management System. Data is recorded in fifteen-minute intervals. 345 Park is likely to incur its on-peak-fee on weekday mornings between December and March. TPO has learned from 23 like weather days in which the building managers have not attempted to preheat, and matched them with 23 preheat days of similar weather. These matched days are based on heat index. Using the energy usage, TPO approximated the total cost for each day based on Con Edison’s billing structure, and whether an on-peak penalty charge was incurred that day. As figure 2 shows, steam usage is similar for the like weather days, but the on-peak penalty greatly exceeds the preheat steam cost making for an approximate Return-on-Investment (ROI) of $175,000 in saving for the winter of 2012-2013 if TPL Preheat recommendations would have been enacted.

73 of 105

No Preheat

350"

Cost ($)

Cost% in% Dollars%

300" 250" 200"

Steam"Cost(No"Preheat)" Steam"Cost(Preheat)"

150" 100"

Preheat

50" 0" 1"

2"

3"

4"

5"

6"

7"

8"

9"

10"

11"

12"

13"

14"

15"

16"

17"

18"

19"

20"

21"

22"

23"

No Preheat

Penalty ($) Penalty(Charge(in(Dollars(

60000"

50000"

40000" Penalty"Charge(No"Preheat)"

30000"

Penalty"Charge(Preheat)" 20000"

10000"

Preheat

0" 1"

2"

3"

4"

5"

6"

7"

8"

9"

10"

11" 12"

13"

14"

15"

16"

17"

18"

19" 20"

21"

22"

23"

Preheat = ~ $175,000 Energy Savings from ~$7,500 in Avoided On-Peak Steam Penal es for an addi onal 23 days in the Winter of 2012-13 (conserva ve). Figure 2. Steam cost and penalty cost for Preheat during building start-up days (red) versus the control of similar weather days that did not use preheating. See Table 2 for a Return on Investment statistical test of 23 days of preheating before 6am compared with a control group of like weather days but with no preheating. In Table 2, a Permutation Test on the Preheat test group versus the No preheat control group yields a probability of statistically different results of p = .27 for cost of the steam used (not statistically different), but p = .004 that Preheat is a non-random improvement in performance over the control group (the Preheat group is statistically different from the control group). While the difference in average steam usage is not statistically significant, the average steam cost is significantly lower for preheat days because of the elimination of on-peak steam usage penalties. These tests suggest that through preheating alone, building managers can significantly decrease energy costs during building start-up while using similar amounts of steam energy; see the table below. Steam Cost ($) Penalty Charge ($)

No Preheat Control Group $211 $35,105

Preheat Test Group $201 $27,774

Permutation Test p = 0.267 p = 0.004

74 of 105

15. Preheating Recommendation Component Instructions Programmer Instructions The preheating recommendation scripts runs on an hourly basis from 15:00 to 06:00 the following day. The main script, recScript.py, runs on an hourly basis from 15:00 to 07:00 the following day. The script runs between December and March. The other two scripts, configParser.py and dbInterface.py, are called by the main script recScript.py. Results from the scripts can be found on the server (e.g., Anderson) as the following table: 345---------000TPOOPTPRHEAT001---001

The current preheating model does not recommend preheat every day. It makes recommendations to minimize the marginal cost of the turn on time of the heat exchangers. Estimates of costs are based on the components of the building’s steam bills. These components include total steam usage, maximum steam demanded over the billing period, and maximum steam demanded between 6 am and 11 am on business days. Each of these components is predicted using extremely randomized regression trees (http://scikitlearn.org/stable/modules/ensemble.html#extremely-randomized-trees). With these predicted components, the total cost for the billing period up to the predicted date can be estimated. The function recommended the turn on time with the lowest estimated cost.

Installation Instructions The script requires: pyodbc v. 3.0.7 numpy v. 1.6.2 scikit-learn v. 1.4.1 python-dateutil 1.5 pytz pandas 0.12.0 The data required for this script is on Rudin/preheat/data/peakERF/. The script loads the models to make recommendations. The scripts: adp.py, configParser.py, and dbInterface.py must be located in the folder Rudin/preheat/. The configuration file config.ini should also be located in Rudin/preheat/ adp.py makes the recommendation for preheat. dbInterface.py queries temperature predictions for 15:00 the day before to 07:00 of the predicted morning to feed into adp.py. It also finds the steam usage from the current billing period. It then writes the recommendation to the Rudin server. configParser parses the configuration file. dbInterface and configParser both require the path to the config file to be explicitly stated.

75 of 105

Configuration Instructions Configurations of the module are in a configuration file. Unless there is a change in the database name or the table name, no changes are needed.

Option

Description

tempPredictions

Name of the outside temperature prediction table

preheatRecs

Name of historical preheat recommendation table

SERVER

Database server

DB

Database name

UID

Username to access the database

PWD

Password to access the database

76 of 105

16. Occupancy Predictions Instructions Programmer Instructions Synopsis: > python predict_occupancy.py [ ] Usage: predict_occupancy.py [options] predict building occupancy based on past observations and other covariates Options: --version show program's version number and exit -h, --help show this help message and exit --cfghelp Show configuration file help and exit. -k LIST, --keys=LIST Comma separated list of configuration keys. --cfgfiles=LIST Comma separated list of configuration files. Standard Options: --running_at=RUNNING_AT determines whether code is running at customer site or at ccls See also 'running_at' option in configuration file help. --python_prog=PYTHON_PROG location of python interpreter See also 'python_prog' option in configuration file help. --perl_prog=PERL_PROG location of perl interpreter See also 'perl_prog' option in configuration file help. --log_level=LOG_LEVEL top level message threshold See also 'log_level' option in configuration file help. --log_console=LOG_CONSOLE set true to add stderr as a log device See also 'log_console' option in configuration file help. --log_console_level=LOG_CONSOLE_LEVEL severity threshold for console logging See also 'log_console_level' option in configuration file help. --log_console_msg_fmt=LOG_CONSOLE_MSG_FMT message format for console See also 'log_console_msg_fmt' option in configuration file help. --log_file=LOG_FILE set true to add a rotating file as a log device See also 'log_file' option in configuration file help. --log_file_level=LOG_FILE_LEVEL severity threshold for file logging See also 'log_file_level' option in configuration file help. --log_file_msg_fmt=LOG_FILE_MSG_FMT message format for log file See also 'log_file_msg_fmt' option in configuration file help. --log_file_dir=LOG_FILE_DIR dir for log file See also 'log_file_dir' option in configuration file help. --log_file_mode=LOG_FILE_MODE mode for log file, w or a See also 'log_file_mode' option in configuration file help. --log_file_maxbytes=LOG_FILE_MAXBYTES max size for log file before rotation See also 'log_file_maxbytes' option in configuration file help. --log_file_backup_count=LOG_FILE_BACKUP_COUNT if non-zero, number of old logs to keep See also 'log_file_backup_count' option in configuration file help. --base_dir=BASE_DIR dir where everything starts from See also 'base_dir' option in configuration file help.

77 of 105

--temp_dir=TEMP_DIR dir for temp files, e.g. bulk insert See also 'temp_dir' option in configuration file help. --data_dir=DATA_DIR static data and destination for models See also 'data_dir' option in configuration file help. --data_sources_dir=DATA_SOURCES_DIR location for data sources See also 'data_sources_dir' option in configuration file help. --control_dir=CONTROL_DIR location for control scripts See also 'control_dir' option in configuration file help. --test=TEST if non-zero, run in module-specific test mode See also 'test' option in configuration file help. --debug=DEBUG if non-zero, print more debugging statements See also 'debug' option in configuration file help. --logger_configured=LOGGER_CONFIGURED if non-zero, calling app has already set up logger See also 'logger_configured' option in configuration file help. --db_driver=DB_DRIVER database driver See also 'db_driver' option in configuration file help. --forecast_granularity=FORECAST_GRANULARITY Interval in minutes between consecutive input/forecasted data points See also 'forecast_granularity' option in configuration file help. --forecast_length=FORECAST_LENGTH forecast length in number of hours See also 'forecast_length' option in configuration file help. --building_ids=BUILDING_IDS comma separated building ids for buildings to process See also 'building_ids' option in configuration file help. --tenant_ids=TENANT_IDS comma separated tenant ids for tenants to process See also 'tenant_ids' option in configuration file help. --training_radius=TRAINING_RADIUS number of days of recent data to use for training See also 'training_radius' option in configuration file help. --use_weather_forecast=USE_WEATHER_FORECAST switch to turn off/on weather forecast usage See also 'use_weather_forecast' option in configuration file help. --svm_dir=SVM_DIR directory for Support Vector Machine programs See also 'svm_dir' option in configuration file help. --svm_uci=SVM_UCI Support Vector Machine format conversion program See also 'svm_uci' option in configuration file help. --svm_scale=SVM_SCALE Support Vector Machine data normalization program See also 'svm_scale' option in configuration file help. --svm_predict=SVM_PREDICT Support Vector Machine prediction program See also 'svm_predict' option in configuration file help. --svm_train=SVM_TRAIN Support Vector Machine training program See also 'svm_train' option in configuration file help. --svm_weight=SVM_WEIGHT Support Vector Machine weight extraction program See also 'svm_weight' option in configuration file help.

Example: To generate predictions as of 7/16/2013 6 pm, python predict_occupancy.py 2013 7 16 18 0

78 of 105

Predicts building occupancy for the next 24 hours starting from the as-of-date for all the buildings specified in the configuration file. If no date is specified, the predictions are generated as of the current system time. Predictions can’t be generated as of a future date. Predictions have 15 minute granularity and are generated using past occupancy observations of the building as well as other covariates like weather. predict_occupancy.py has been designed to be run once every hour

Installation Instructions The module expects about 13 months of past occupancy observations and weather data to do the predictions. It may be able to function with less data but the predictions may be inferior. The module uses the output of the occupancy model optimizer, which must be set up to run once a day. Location: Rudin/occupancy Synopsis: > python cross_validate.py Description: Computes optimal occupancy model parameters for each building specified in the configuration file. This module uses the feature set files created by the corresponding predictor module. It also cleans up old feature set files. In addition, the corresponding evaluator module scores the output of the predictor. It can be setup as a scheduled task to be run once a day. Location: Rudin/occupancy Synopsis: > python score_prediction.py Description: Computes the Root Mean Squared Error (RMSE), Mean Absolute Error (MAE) and Mean Absolute Percentage Error (MAPE) for occupancy predictions for the last 30 days for all the buildings specified in the common configuration file and saves the results to the database. If scores already exists for a given day, they are updated/overwritten. Location of the files, where it should be installed? Rudin/occupancy, Rudin/common_rudin Once installed, what configuration script needs to be run? None

Configuration Instructions This module reads the user-configurable settings from the common configuration file. [] building_db = 345

79 of 105

building_db_server = anderson.ldeo.columbia.edu db_user = rudin_db_user2 db_pwd = rud1n2013$ holiday_table = building_open_hour = 7 building_close_hour = 19 weather_station_id = weather_central_park_nyc ; results database results_db = 345 results_db_server = anderson.ldeo.columbia.edu results_db_user = rudin_db_user2 results_db_pwd = rud1n2013$ predict_occupancy = 0 occupancy_table = xval_results_table_occupancy = results_table_occupancy = score_table_occupancy = train_covariate_filename_fmt_occupancy = \w+_occupancy_%s_train_hour_(\d+)\.csv

On a daily basis, is there daily configuration that needs to be run? No

80 of 105

17. Topic Discussion on Now-Cast Recommendations Now-Cast Recommendations within the Columbia University Total Property Optimizer (TPO) for Steering Space Temperatures for Optimal Operations of High-Rise Office Buildings Forty percent of the energy usage in Manhattan is consumed in producing the comfort and safety of tenants in high-rise office buildings. In turn forty percent of all building energy costs goes to maintaining and operating the HVAC air conditioning and heating systems. As the world moves into the big-data age, the opportunity to optimize and build more secure and efficient energy systems is critically important. Columbia’s TPO is a forecasting engine for the Di-BOSS Digital Building Operating System that is designed to lower that percentage of energy use using computer aided energy efficiency techniques. For example, the American Society of Heating, Refrigerating, and Air Conditioning Engineers (ASHRAE.org) estimates that every degree eliminated from overheating each building in winter and overcooling in summer will save 6% in energy consumption (c.f. New York Times, July 21, 2013, What’s Cooler than Cool? By G. Bellafante). High-Rise office buildings are by lease, obligated to provide comfortable spaces to the tenant companies that they house. The operation of these skyscrapers is of great importance, and is a fundamental baseline for the success of tenant companies and ultimately of the economies they drive. The buildings also occupy a very important business space, affecting the decisions of local government and power-grid companies, as well as providing necessary services of housing, security, power, and infrastructure to their tenants. Though the buildings provide a wide array of services to these tenants, one of the most difficult and expensive parts of their operation lays in maintaining appropriate and cost-effective climate control systems. The Now-Cast module of the Total Property Optimizer (TPO) is a human-in-the-loop system, which uses advanced analytics to provide building operators with the ability to steer the building to the most efficient energy comfort level floor-by-floor. The Now-Cast module of TPO uses its Support Vector Machine learning system to learn the thermodynamic response of each floor to HVAC set point changes, and uses supply air and return air temperatures along with real-time monitoring of space temperatures on each floor to steer the floor using the TPO Horizon Indicator (Figure 1).

81 of 105

Perfect Temperature Horizon Indicator Engineers can Con nuously Steer to 2 hour ahead ‘Nowcast” throughout the Day Now Start-up

Actual Predicted by the Machine Learning Forecaster

Machine Learning Now-cast (Red) allows Engineers to steer the Perfect Temperature Horizon for Tenant Comfort (Green band) a er Start-up every morning –– which saves the Building Owner ~ $1700 of energy costs per day and

(Figure 1.) TPO follows an operational philosophy of maintaining a robust and expressive human--in--the-loop system to utilize engineer/operator expertise in arriving at optimal building operation strategies. Though there are automated control systems at work in the building management system (BMS), ultimate control is left in the hands of the building operators, who utilize specific control levers, most often in temperature set point values, to maintain the individual floor space temperatures. The Now-Cast takes those set points and the history of floor-by-floor performance in similar weather conditions to forecast the response of each floor two hours into the future to the now-settings. The Now-Cast space temperature trajectory suite of machine learning sits atop a primary layer of 24-hour predictions, and gives insights into and makes predictions about the effects of the current setting of the buildings temperature values and the values of the building operator’s control levers on ambient space temperature. Utilizing both historical and predicted data, it uses a blend of relevant covariates to guide the building operators in ensuring their decisions will not break tenant lease requirements. This, in short, takes any guess-work out of the building’s operation. Each run of the suite provides temperature predictions for 2 hours, resulting in 8 predictions (at 15 minute resolution) per floor. The Now-Cast uses a space temperature trajectory machine learning suite that relies on 3 forms 82 of 105

of input data: 1.) real-time space temperature values: The real-time BMS data feed provides a view of the current temperature of the air in critical parts of the building. Basic thermodynamic modeling allows the Now-Cast to identify correlative relationships between the various air and water temperature HVAC settings and the ambient space temperatures. 2.) levers of control: The real-time BMS data also provides a view of the current set point values for a variety of the engineering team’s control systems. These are often in the form of thermostat set point values. 3.) 24-hour predictions A separate module of the TPO machine learning suite uses a variety of covariates to predict 24-hour forecasts for space temperature, steam use, and electricity use, amongst others. By using the predictions for space temperature, TPO is able to learn the past thermodynamic response of the normal operations of the building, floor-by-floor. Adding the 24-hour forecast predicted values to this past history, TPO is able to include an abstract covariate set into the Now-Cast predictions. Intrinsically, the Now-Cast includes covariates like current occupancy, outside weather and tenant response to holidays. The nature of the Now-Cast as time series data allows for robust covariate generation. Current generation techniques look at trajectories (relative change over varying timescales), volatility, total change in values, and percentage of maximum to generate the parameter set to identify the regression function tying all of the input variables and control levers to the output space temperatures two-hours into the future. Beyond time--series derived data, single variable covariates like current time of day and current temperature values are also used. The Now-Cast space temperature trajectory suite uses kernelized support vector regression to make TPO’s estimates of temperatures in the near-term future. Support vector regression is a regression derivative of the support vector machine classification algorithm, which uses the concept of maximizing a dividing hyper-plane as the methodology to learn the functional mapping between the input and output spaces. Through use of a Radial Basis Function (RBF) kernel, the Now-Cast is able to employ the ‘kernel trick’ to account for and discover the nonlinear relationship between input variables and output predictions. The current implementation utilizes a daily grid-search to find optimal parameters, and uses such staples as k-fold cross validation in this parameter optimization. The resulting usage of the TPO Now-Cast in the engine room by operators at 345 Park Avenue is shown in Figure 2. Over the winter heating season, the average space temperatures for the 44 floor, ~2 million square foot High-Rise office building were steered into the Horizon Indicator. 1.5 degrees F of overheating for the 20 million cubic feet of tenant space was eliminated, resulting in a conservative estimate of savings of ~$75,000 from a 7% reduction in energy

83 of 105

consumption… in line with the estimates of ASHRAE.

Average Space Temperature (Degrees)

Improved Comfort over whole Building a er TPO Nowcast installed in Engine Room

1.5˚ Temperature Improvement in Comfort over 20 million cu of Space at 345 Park Avenue resulted in Steam savings of~ $1200/day and $25,000/month = ~$75,000 for winter/spring hea ng season 2013

(Figure 2.)

Here is the operations script for recommendation on NowCast:

D:\Rudin\spaceTemperature_trajectory\nowCast.py Runs the now-cast procedure, takes two parameters, namely the name of the building and the location of the configuration file. Also it takes an optional argument, namely gridsearch, to be carried out less frequently (i.e. every day rather than every hour) for model selection.

84 of 105

18. Web Component Instructions Operator Instructions TPOWEB is an ASP.NET web application that is accessible using standard web browsers including Internet Explorer, Firefox, Chrome, and Safari. There are two ways to launch the TPOWEB. 1> Launch TPOWEB from main Di-BOSS dashboard. For example, a. First login Di-BOSS at https://diboss.selex-es.com/ b. For a specific building, click the TPO button on the right, as illustrated below

2> Access TPOWEB directly through URL http://localhost/TPO with localhost to be the hostname of the web server. The login is ccls and password is columbia. This direct access is not recommended.

After entering the TPOWEB application, user can then click various icons to enter different functional web pages, as illustrated below

85 of 105

86 of 105

87 of 105

88 of 105

Are there any command or script that needs to be run daily, hourly, etc.? No.

Installation Instructions There are two parts for installation of TPOWEB. 1. Database server installation: restore TPOWEB database backup or copy TPOWEB database to an existing MS SQL 2008 R2 database server. Create a login user with read and execute (stored procedure) permissions. 2. Web server installation: copy web directory or unzip TPO.zip to web directory C:\Web\TPO and then set up the web application http://localhost/TPO with ASP.NET v4.0 framework. Location of the files, where it should be installed? The recommended installation directory is C:\Web\TPO or other drive:\Web\TPO. Once installed, what configuration script needs to be run? Open Internet Information Services (IIS) Manager and set up this directory as a web application http://localhost/TPO. In the Basic Settings, choose ASP.NET V4.0. Open Windows Explorer and set the permission of directory C:\Web\TPO\TempImageFiles\ to be writeable by Users.

Configuration Instructions The main configuration file is C:\Web\TPO\Web.config as below. The database connection string “TPOWEB” needs to be customized for the specific database being deployed. The temporary image directory needs to be defined with “ChartImageHandler”. The login authentication mode is “Forms” and the login page URL is “Login.aspx”.

89 of 105

On a daily basis, is there daily configuration that needs to be run? No.

90 of 105

Appendix 19. Appendix - Issue Tracking and Change Management – Redmine We have chosen Redmine as our project management web application. Some of the main features we will use of Redmine are: Issue tracking system SCM integration (SVN, CVS, Git, Mercurial, Bazaar and Darcs) Multiple projects support Role based access control Gantt chart and calendar News, documents & files management Feeds & email notifications Per project wiki Per project forums Issue creation via email We have configured the system to have a Di-Boss project and under it TPO. Di-Boss has issue trackers and TPO has issue trackers and also our SVN repository associated with it. In addition, under the Di-Boss project is a Project representing all the Rudin Properties and under that each building that has Di-Boss installed. Each property has issue trackers for startup and rampdown. We have configured our Redmine installation to receive issue emails. Emails can be sent by Rudin building operators to be ingested by the system. Project Hierarchy Di-Boss Rudin Properties o Rudin 345 Park Ave o Rudin 560 Lexington Ave TPO

91 of 105

Figure 3: Redmine project view showing created project heirarchy for Di-Boss

92 of 105

Figure 4: Overview page for Di-Boss overall project, Showing one bug issue and 11 feature issues as well as a Rampdown and Startup item

The startup and rampdown trackers receive emails on startup and rampdown times using Redmine’s issue creation via email feature. More about that is below.

93 of 105

Figure 5: The Roadmap View for TPO. It shows the Beta Version and all the related Issues (in this case only Features) associated with the Beta Version

94 of 105

Figure 6: The Issue Creation View besides the usual items associated with an issue, allows for associated files and screen images and watchers that will receive emails on status changes on the Issue.

95 of 105

Figure 7: The Gantt View for TPO and its Beta Version below it. All the Issues (in this case only Features) become tasks in the Gantt chart

96 of 105

Figure 8: The Calendar View for TPO

97 of 105

Figure 9: This is a view of the TPO’s SVN repository in Redmine

98 of 105

Figure 10: Here is the Wiki View for TPO. The News View looks similar to this.

99 of 105

Figure 11: The Document View allows user and technical documents to be uploaded to be associated with a project.

100 of 105

Figure 12: The File View is similar but allows files and general to be uploaded and associated with a Version. This includes screen capture images.

101 of 105

Figure 13: The Activity View is a log of Redmine actions associated with the Project

Startup/Rapdown Tracking & Bug/Feature emails We have designed a way to use Redmine’s trackers to receive daily Preheat, Ramp Up and Ramp Down submissions from a form developed by Rudin IT (Figure 13) submitted by Rudin Building Operators. The form, as part of a word document on the operators desktop, emits an email sent to [email protected]. This makes use of the fact that we configured our Redmine instance to receive issues via email. We created a Redmine project for each building. (This project could also track any implementation issues with the building itself – say a BMS problem.) What is illustrated below works for Issues (Bugs, Features, etc.) associated with Di-Boss or TPO. Note that the form (Figure 13) has some logic to grey out irrelevant fields depending on, for example, if the building is being heated or cooled. Also note the exemption feature. Operators can indicate whether the building operation or the data being used to make operational decisions should be treated as an exemption and not considered in a machine learning training set. The exemption has a start and end time to it.

102 of 105

Figure 14: A summary of the Operator Feedback Issues that have been collected for 345 Park, via the Visual Basic form developed by Rudin’s IT department.

103 of 105

Figure 15: The Visual Basic form developed by Rudin’s IT department used by the operators to submit Preheat, Startup & Rampdown reports.

104 of 105

Figure 16: Here is the database view of Issues. SQL queries can harvest the data.

A SQL query like: SELECT * FROM [REDMINE].[dbo].[issues] where tracker_id in (14) and project_id in (6,7) will select all the feedback Issues for 345 and 560.

105 of 105

Total Property Optimization (TPO) System Design

Total Property Optimization (TPO) System Design

Suggest Documents

TPO

Profitable Property Management - Total Care Property Management

Untitled - St Lucie TPO

Mooring system design optimization using a surrogate

Design Optimization of Feeding System and ... - ScienceDirect

Optimization in Data Cube System Design - CiteSeerX

System Design Optimization for MCM

Design and Optimization of a Total Vaporization Technique Coupled ...

Leakage Aware Digital Design Optimization for Minimal Total Power ...

(TPO) and JAK2

(tpo) roofing membranes

TPO Induces PI3K

Untitled - St Lucie TPO

Intellectual Property Re-use in Embedded System Co-design: an ...

- HINO Total Support System

Total Digital Imaging System

Total Design of Active Neck Support System for ... - TU Eindhoven

Design of an Advanced Bearing System for Total Knee ... - MDPI

TPO (1).pdf - Google Drive

TPD/TPR/TPO - ZetA Partikelanalytik

TPO Connect Key Dates & Docs

Towards Query Optimization for SPARQL Property Paths

Kazhdan's Property (T) via semidefinite optimization

Real Estate Property Collaboration System