A Hybrid Computational Model for Building Systems Control

Seongju Chang School of Architecture Carnegie Mellon University

Ph.D. Committee Prof. Ardeshir Mahdavi, Ph.D.(Chair) Prof. Volker Hartkopf, Ph.D. Prof. Sebastian Thrun, Ph.D. Prof. Bernd Bruegge, Ph.D.

Table of contents
Table of contents..................................................................................................................................................i List of Figures.....................................................................................................................................................ii List of Tables......................................................................................................................................................vi Acknowledgment................................................................................................................................................vii Copyright Declaration......................................................................................................................................viii Abstract...............................................................................................................................................................ix

Introduction ........................................................................................................................1
1.1 1.2 1.3 Motivation............................................................................................................................................1 Thesis goals & hypotheses...................................................................................................................3 Thesis outline.......................................................................................................................................4

Background.........................................................................................................................6
2.1 Building process and its control...........................................................................................................6 2.1.1 2.1.2 2.1.3 2.2 Overview..............................................................................................................................6 Daylight and electrical lighting process ..............................................................................7 New perspective on building control process ......................................................................9

Models for building process control ..................................................................................................10 2.2.1 2.2.2 Simulation model...............................................................................................................10 Machine learning model ....................................................................................................16

HISSTO: a hybrid system for environmental control ..................................................21

3.1 Problem identification........................................................................................................................21 3.1.1 3.2 Issues in building control models ......................................................................................21

Requirement elicitation......................................................................................................................24 3.2.1 3.2.2 Functional requirements ....................................................................................................24 Non-Functional requirements ............................................................................................30

3.3

System analysis..................................................................................................................................32 3.3.1 3.3.2 3.3.3 3.3.4 Analysis of hybridization...................................................................................................32 System analysis object model ............................................................................................34 System sequence model .....................................................................................................35 User interface mock-up......................................................................................................37

3.4

System design ....................................................................................................................................39 3.4.1 3.4.2 3.4.3 System architecture............................................................................................................39 System component design .................................................................................................40 Concurrency identification ................................................................................................52

3.4.4 3.4.5 3.4.6 3.4.7 3.4.8 3.4.9 3.4.10 3.4.11 3.5

Hardware/software mapping..............................................................................................52 Data management ..............................................................................................................54 Global resources management ...........................................................................................55 Software control implementation ......................................................................................56 Boundary conditions ..........................................................................................................60 Adaptation to the system changes......................................................................................62 Design priorities.................................................................................................................63 Design trade-off .................................................................................................................63

Object design .....................................................................................................................................64 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 3.5.6 Object design of the Predictor ...........................................................................................64 Object design of the Tester ................................................................................................83 Object design of the Commander ......................................................................................88 Object design of the Sensor ...............................................................................................89 Object design of the Actuator ............................................................................................90 Object design of the daylight responsive lighting control .................................................90

System test & evaluation .................................................................................................96

4.1 4.2 Test bay & control target systems......................................................................................................96 Data acquisition for system test .........................................................................................................99 4.2.1 4.2.2 4.3 Analysis of the measurement...........................................................................................100 Data preparation for testing the predictors ......................................................................102

Performance test of the predictors ...................................................................................................104 4.3.1 4.3.2 Prediction performance of the LUMINA.........................................................................104 Prediction performances of the hybrid predictors............................................................106

4.4

Test of predictive control scenarios .................................................................................................121 4.4.1 4.4.2 4.4.3 Test of simulation-based control......................................................................................121 Test of hybrid predictor-based control.............................................................................124 Test of the convergence time to reach a control action decision .....................................126

4.5

Overall evaluation of HISSTO ........................................................................................................128

Conclusion.......................................................................................................................130
5.1 5.2 Contributions ...................................................................................................................................130 Future Research ...............................................................................................................................131

References .......................................................................................................................133

Appendix A: HISSTOs test instrumentation Appendix B: HISSTOs control performance evaluation

ii

List of Figures

Figure 2.1: Daylight and electrical light process in a space ................................................................................9 Figure 2.2:Feed-forward (a) and feed-back (b) control process........................................................................12 Figure 2.3: Feed-forward control process example ...........................................................................................12 Figure 2.4:: Use of BDI and GAT for simulation-assisted building control (Mahadavi, 1997)........................13 Figure 3.1:Use case diagram of HISSTO: UML notation .................................................................................30 Figure 3.2: Structure of a virtual building and its relationship with other entities............................................32 Figure 3.3:Typical hybridization schemes between a simulator and a machine learner ...................................34 Figure 3.4: System analysis class diagram of HISSTO: UML notation............................................................35 Figure 3.5:Sequence diagram illustrating interactions among the key objects in HISSTO: UML notation .....36 Figure 3.6: HISSTOs Monitoring Window on the web....................................................................................37 Figure 3.7: HISSTOs Control Window on the web..........................................................................................38 Figure 3.8:Component diagram describing HISSTOs system architecture: UML notation ............................40 Figure 3.9:Top level logical model describing HISSTOs subsystem breakdown: UML notation ...................41 Figure 3.10:Logical model of HISSTOs SystemManager component: UML notation....................................42 Figure 3.11:Logical model of HISSTOs EnvironmentDescriptor component: UML notation ........................43 Figure 3.12:Logical model of HISSTOs MonitoringManager component: UML notation .............................44 Figure 3.13:Logical model of HISSTOs EventManager component: UML notation ......................................45 Figure 3.14:Sequence diagram showing HISSTOs event handling process: UML notation............................46 Figure 3.15:Logical model of HISSTOs PredictionManager component: UML notation ...............................47 Figure 3.16:Logical model of HISSTOs ControlManager component: UML notation ...................................48 Figure 3.17:Logical model of HISSTOs DatabaseManager component: UML notation .................................49 Figure 3.18:Logical model of HISSTOs CommunicationManager component: UML notation......................50 Figure 3.19:Logical model of HISSTOs UserInterfaceManager component: UML notation..........................51 Figure 3.20:Deployment diagram describing HISSTOs hardware topology: UML notation...........................54 Figure 3.21: Physical connectivity for HISSTOs system instrumentation .......................................................54 Figure 3.22: Access privilege management in HISSTO: UML notation...........................................................55 Figure 3.23: HISSTOs event notification process based on the Observer design pattern: UML notation.......57 Figure 3.24: HISSTOs alternative control strategies based on the Strategy design pattern: UML notation ....58 Figure 3.25:State transition diagram describing HISSTOs control mode changes: UML notation .................59 Figure 3.26: HISSTOs handling of control command based on the Command design pattern: UML notation60 Figure 3.27: Construction of a View based on the Builder design pattern: UML notation ...............................62

iii

List of Figures

Figure 3.28: Viewer information necessary for LUMINAs glare calculation ..................................................65 Figure 3.29:Iconic representation scheme of the neural networks designed for HISSTO.................................71 Figure 3.30: Generic architecture of the neural networks design in HISSTO ...................................................73 Figure 3.31: Different neural network training schemes based on the progression of time ..............................75 Figure 3.32:Collaboration diagram describing SM12CNNs training process: UML notation.........................79 Figure 3.33:Collaboration diagram describing SM12CNNs prediction process: UML notation.....................80 Figure 3.34:Exemplary collaborative process between WFNN(2) and BRIDGENN in WFC1NN..................81 Figure 3.35: Training and operation processes of the different hybrid predictors in HISSTO..........................83 Figure 3.36: Exemplary preference functions for HISSTOs performance indicators ......................................87 Figure 3.37:Activity diagram of HISSTOs daylight responsive lighting control process: UML notation........92 Figure 4.1: Intelligent Workplace at Carnegie Mellon University as the system test bed ................................96 Figure 4.2: HISSTO system test bay at the Intelligent Workplace....................................................................97 Figure 4.3: Illustrative photos showing exterior and interior of the test bay ....................................................97 Figure 4.4: Plan and elevation view of the test bay with louver, luminaires, and indoor sensors.....................98 Figure 4.5: Daylight station on the top of the IW measuring sky condition parameters...................................99 Figure 4.6:Sky illuminance and irradiance measurements on a typical clear day (3/13/98)...........................100 Figure 4.7:Sky illuminance measurement showing daily and seasonal variations .........................................100 Figure 4.8:Indoor illuminance profile on all reference points influenced by the louver angle changes .........101 Figure 4.9:Indoor illuminance profiles depending on the sensor positions and louver angles (3/13/98)........102 Figure 4.10:LUMINAs indoor illuminance prediction performance in the test bay ......................................105 Figure 4.11:Relative error of LUMINAs indoor illuminance prediction .......................................................106 Figure 4.12:Histogram showing LUMINAs relative indoor illuminance prediction error distribution .........106 Figure 4.13:Learning curves of the neural networks in HISSTO....................................................................107 Figure 4.14:Different hybrid predictors indoor illuminance prediction accuracy expressed in RMS of relative errors (Test case 1with D1 and D2 data sets in Table 4.1)................................................................109 Figure 4.15:Different hybrid predictors indoor illuminance prediction accuracy expressed in RMS of relative errors (Test case 2 with D4 and D5 data sets in Table 4.2)...............................................................110 Figure 4.16: Different hybrid predictors performance in predicting both reference parameters and performance indicators represented as the averaged relative distances from the simulators prediction...............111 Figure 4.17: Average relative distance and standard deviation of hybrid predictors reference parameters and preference indicators prediction from the simulations (with D1 and D2 data sets in Table 4.1)......113 Figure 4.18: MS1NNs indoor illuminance prediction accuracy with the selected training sensor position....114

iv

List of Figures

Figure 4.19:WFC1NNs indoor illuminance prediction performance (a) and RMS of the predicted performance indicators relative deviations from the simulations (b) with different calibration sensor points....115 Figure 4.20: Indoor illuminance prediction decay curves of the hybrid predictors in HISSTO ...................... 116 Figure 4.21: Decay curves of the hybrid predictors predictions for the reference parameters and performance indicators expressed in terms of their relative distances from the simulation output......................117 Figure 4.22: Change adaptation performance of each hybrid predictor in indoor illuminance prediction...... 118 Figure 4.23: Change adaptation profile calculated as the closeness of each hybrid predictors reference parameters and performance indicators prediction to the simulation output ...................................119 Figure 4.24:Overall evaluation of the hybrid predictors in a graphical form ..................................................120 Figure 4.25: Mapping between ranked louver positions and control quality index ........................................122 Figure 4.26: Time requirements comparison needed for a single control time window .................................127

List of Tables

Table 2.1: Factors influencing thermal and lighting process in a building..........................................................7 Table 3.1: Examples of the challenges in energy simulation validation process ..............................................22 Table 3.2:Visionary scenarios of HISSTO ........................................................................................................25 Table 3.3:HISSTOs use cases...........................................................................................................................29 Table 3.4: Design priorities of a typical building control system......................................................................63 Table 3.5: Input and output parameters for LUMINA.......................................................................................66 Table 3.6: Input and output parameters for the neural networks designed in HISSTO.....................................69 Table 3.7:Selected input (I) and output (O) parameters for each neural network designed for HISSTO .........70 Table 3.8:Design characteristics of the neural networks to construct HISSTOs predictors.............................72 Table 3.9:Diagrammatic description of each hybrid predictors prediction process .........................................82 Table 3.10: Various sensors used in HISSTO....................................................................................................89 Table 3.11: Louver operation schedule example ...............................................................................................94 Table 4.1:Test data sets filtered by the validation criteria (see A.2.1.1) .........................................................103 Table 4.2: Test data sets within 20 % deviation range from the Perez model prediction .............................103 Table 4.3: Neural network training data sets generated by the weather file based simulations ......................103 Table 4.4:Example of typical simulation validation methods .........................................................................104 Table 4.5:Overall evaluation of the hybrid predictors designed in HISSTO...................................................120 Table 4.6:Overall evaluation of the daylight control test ................................................................................122 Table 4.7:Percentage of instances with a specific control quality index .........................................................123 Table 4.8:Initial state for the inputs to the predictor........................................................................................123 Table 4.9:10 best control actions suggested by the pure simulator .................................................................123 Table 4.10:Order of the best louver positions suggested by the simulator......................................................124 Table 4.11:10 best control actions suggested by the simulator + luminaire matrix predictor .........................124 Table 4.12:Order of the best louver positions suggested by the MSC0NN predictor .....................................125 Table 4.13:10 best control actions suggested by the MSC0NN predictor.......................................................125 Table 4.14:Order of the best louver positions suggested by the WFC1NN predictor .....................................125 Table 4.15:10 best control actions suggested by the WFC1NN predictor.......................................................126 Table 4.16:Final systems control states (with utility values) suggested by the tested predictors....................126 Table 4.17: Comparison of the required time for HISSTOs different controllers..........................................128 Table 4.18:Assessment of the research outcome including HISSTO implementation....................................129

vi

Acknowledgment

It has been a long journey through which I learned that life has many hidden layers to be discovered. I feel sincere gratitude to Professor Ardeshir Mahdavi who brought a great range of expertise and interest to my work. He has been an ever-present source of guidance and encouragement throughout my doctoral program residency.

I should like to thank Professor Volker Hartkopf for his visionary inspirations and support, letting me perform necessary experiments at the Intelligent Workplace. Surely, an essential part of contribution came from Professor Sebastian Thrun through his continuous enthusiasm, commenting and answering my machine learning related questions with unsurpassed clarity. Professor Bernd Bruegge has been passionate and resourceful in bringing object-orientation and component technology into my thesis system development effort. I treasure the time spent with him and his ambitious students at the software engineering laboratory.

It would certainly have been much difficult if I had not have my colleagues around, lending me their shoulders to lean on, providing invaluable moments of friendship. Among those deserve being named, I want to thank Vineeta Pal for sparing her time to discuss the issues involved in her daylight simulation program with me. It is she who has been always willing to be victimized by my run-time humors even when I broke her no-more-than-ten-minutes rule on purpose. I also thank Jamieson Shulte at the School of Computer Science for his help in the instrumentation of my thesis experiments as well as the neural network implementation. To those named persons, I must add Rohini Brame, Paul Mathew, Robert Ries, and Jay Shankavaram for their friendly help and knowledge exchanges with unexpected occasional laughters.

I owe many thanks to my family members, especially to my mother whose unconditional support and trust made this thesis finally see the outside world. I dedicate this thesis to her with love and respect.

vii

Copyright Declaration

I hereby declare that I am the sole author of this thesis.

I authorize Carnegie Mellon University, Pittsburgh, Pennsylvania to lend this thesis to other institutions or individuals for the purpose of scholarly research.

I authorize Carnegie Mellon University, Pittsburgh, Pennsylvania to reproduce this thesis by photocopying or by other means, in total or in part, at the request of other institutions or individuals for the purpose of scholarly research.

Copyright c 1999 by Seongju Chang

viii

Abstract

The increased complexity in building systems integration provides a new challenge for building operation process. A wide distribution of the direct digital control approach has inspired researchers and engineers to pay more attention to the computational solutions in building control. The enhanced knowledge about building systems behaviors as well as the increased computing power make attractive the potential use of a computational building model as the agent to carry on building control task. On the other hand, some simulation programs are computationally too intensive to be effective for real-time control purpose. A machine learner can address this problem. However, it often requires large amount of data for training or retraining, which makes the technique inevitably sensor-dependent. This thesis intends to demonstrate that analytical approaches (i.e. simulation) and inductive learning methods (i.e. neural networks) can cooperate to facilitate building systems control. In this process, the role of a simulator is augmented as the source of the system knowledge by which a supervised learner, implemented in neural networks, is trained for faster predictions. A machine learner, trained either to replace a simulator or to predict the simulation error, serves as the pivotal component for a better predictor through a hybridization process.

This thesis has computationally implemented and tested seamless control scenarios based on the different hybridization schemes in order to identify desirable processes for such hybridization. The hybrid constructs designed to explore diverse synergistic effects have been tested in daylight responsive lighting control domain. Multiple hybrid controllers are designed to meet four control goals: enriching the informational repertoire of systems control operations for lighting (by inclusion of performance indicators for glare and solar gain), reducing the number of sensing units necessary for capturing the states of buildings visual performance indicators in real time, enhancing the accuracy of predictions necessary for the identification of the best control option, and maximizing the searches in the lighting system control state space within a limited time.

HISSTO (Hybrid Intelligence for System State Transition Operation), the resulting pilot hybrid control system is capable of regulating target lighting systems effectively by covering a wider portion of the control state space with increased agility and precision even in the environments subject to dynamic changes. HISSTO demonstrates that the various modes of user-system interactions can be facilitated by using component-based object-oriented software engineering techniques along with internet-activated control and monitoring interfaces. HISSTOs software design pattern driven modular system architecture also allows it to be easily extended even to the other building control domains.

ix

Introduction

1.1

Motivation
Traditionally, building control systems have operated based on a homeostatic short-term feed back mechanism. For example, thermostatic control of HVAC components involves typical operations (on/off, change in volume and/or temperature of heating/cooling media, etc.) that are essentially guided by temperature sensing in a space. More recently, building control systems have become increasingly sophisticated. One of the approaches has been to utilize various methods and tools (including neural networks) to accurately capture a buildings dynamic characteristics so as to provide a more reliable basis for the control of its behavior (Curtis 1996, Mistry and Nair 1993). In this scenario, control options can be improved ("optimized"), as their past impact on the buildings dynamic behavior is reflected in the collected information by the sensing system. Capturing buildings dynamic behavior toward enhanced control strategies can be supported using advanced computational performance simulation routines. Generate-and-test as well as bi-directional inference methods can be used to derive preferable control schemes and required values for control variables based on parametric and iterative simulations (Mahdavi 1997b).

A building used to be considered as a static and a passive physical construct. This view has been significantly challenged by the growing complexity of various building systems and components as well as the dynamic interactions among them. For example, because of the thermal inertia associated with a building, the effect of external environmental changes on building interior conditions takes place over a time scale on the order of hours. These dynamics make control action take place on a time scale: on the order of seconds for actions involving local control loops, to a time scale on the order of minutes for changes in zone conditions (Kelly et al. 1984). Such dynamism makes a building systems control task a complex and sophisticated process. Most of the building processes can be quite accurately predicted using a set of well-established models, yet some of them still remain to be constantly monitored. This research starts from the idea that a well organized hybrid construct out of both simulation and machine learning technique can support the control of a dynamic building process such as the visual environment in a building.

Developing a hybrid computational model for building control is the major focus of this thesis. There have been many hybridization efforts in control domain, but few of them, if any, addressed 1

the issue of combining model with machine learning techniques, especially for the visual environment control in a building. At the same time, a well-defined evaluation scheme for different control system designs and implementation options is also important. Normally, the evaluation criteria of the visual environment in a building has been limited to very few quantitative indicators such as illuminance and uniformity. Enriching the performance evaluation criteria is, therefore, highly desired as long as the control system can deal with resulting complexity in both generation and assessment of control options. Identifying potential synergistic effects between simulation and machine learning for an enhanced building systems control can be attempted through a hybridization process. Hybridization of different models or components is not an entirely new approach, since there have been such attempts as neuro-fuzzy systems and neural network assisted PID controllers (Curtis 1996). For example, PID control algorithm using a feed-back loop with three mathematical terms: proportional, integral, and derivative works with well-behaved linear, cumulative, and time-variant processes. But under non-linear conditions, this algorithm can yield unstable control outputs unless it is tuned correctly. A neural network could serve for this tuning purpose. The major motivation for the hybridization between simulation and machine learning in this thesis lies in the importance of prior knowledge in learning process. It has been argued that prior knowledge can help significantly in learning (Mitchell 1997) and simulation can provide such knowledge to a machine learner. In this scheme, the role of building simulations can be augmented as the source of the system knowledge. Simulation can assist the identification of control-sensitive variables. The mapping between possible states of a system and their outcomes useful for the training or retraining of a machine learner can also be provided by simulations. Both data dependency and sensor dependency in neural network implementation can be dramatically reduced in this process. Beyond enhancing the effectiveness of dynamic control systems, the additional benefits of the suggested approach include:

Prediction of the effects of the changes to building hardware and its control systems Beta-testing of building control system hardware based on the simulated actions in the context of a virtual building

Pre-training of machine learning systems simulation data on building behaviors prior to their field utilization

Retraining of machine learning systems to account for the effects of abrupt modifications to building configuration (i.e. retrofit) using simulation data

Reduction of the number of sensing units necessary for capturing building's real-time operational status

On the other hand, a machine learner can be utilized for on-line simulation calibration. This tuning process can improve the performance of simulation predictions. A machine learner can also copy the simulators knowledge so that it can reduce the time and computational load significantly in predicting the outcome of control actions after the training is completed. This benefit could lead to a major improvement in building control performance as long as the proper design and implementation of the hybridization are achieved. By combining a simulation model and a machine learning technique such as neural networks, some of the critical issues in model-based control can be resolved. The expected benefits that simulation model can have when it is combined with machine learners are as follows:

Calibration of simulation outcomes by compensating for the simulators prediction error Reducing computational load and time in predictions by copying and replacing a simulator

In order to realize this idea, a conventional building automation system must be supplemented with a multi-aspect virtual model of the building that runs parallel to the building's actual operation. While the real building can only react to the actual contextual conditions (i.e. sky luminance distribution pattern, occupancy) and building control actions, the simulation-based virtual model allows for additional operations: i) the virtual model can move backward in time so as to analyze the buildings past behavior and/or to calibrate the model toward improved predictive potency; ii) the virtual model can move forward in time so as to predict the buildings responses to the various alternative control scenarios (Mahdavi et al. 1999).

Interactive and modular building control software development is the other driving force of this thesis. The primary motivation for the thesis system development effort is to be able to dynamically change the values of control parameters on-line while the system allows implementationindependence and flexible future extension.

1.2

Thesis goals & hypotheses

The scientific goal of this thesis is to verify the benefits of the hybridization between simulation and machine learning technique in building control domain. The engineering goal is to identify a prototypical building control software architecture allowing flexible adaptation to dynamic environmental and user preference changes. To summarize, the major goals of this thesis are to identify:

TG1) Hybridization architecture between a simulator and a machine learner for high-performance building control operations with increased speed and accuracy.

TG2) Well organized building control software architecture for enhanced accessibility, change adaptability, and interoperability while being successfully integrated with the developed hybrid computational models

The fulfillment of the scientific thesis goal (TG1) will be tested against the following hypotheses:

TH1) Hybrid prediction model can increase the speed of convergence to a control decision.

TH2) Hybrid prediction model can increase the accuracy of predictions for more precise control.

TH3) Hybrid prediction model can decrease the sensor dependency of control operations while enriching the performance evaluation criteria involved in control action decision process.

TH4) Hybrid prediction model can provide better chance for the control system to adapt to building configuration or environmental changes.

TH5) System flexibility can be maximized by using design patterns and component-based objectoriented programing methodology.

The engineering thesis goal (TG2) will be tested against the systems use cases and non-functional requirements described in Chapter 3, system requirement elicitation section.

1.3

Thesis outline
This thesis involves a system development effort and the experiments for the developed system validation. As is stated, demonstrating the performance enhancements of the hybrid prediction models in building control domain is critical. For this reason, multiple hybridization schemes in the various forms of computational models are designed, implemented, and tested. These prediction models are combined with a testing algorithm which performs control options evaluation task to produce the most appropriate control decision. Different controllers based on the different hybrid prediction models are then evaluated in the visual environment control operation of an actual building. The performance of each controller is evaluated against measurement. Both the predictors and the controllers using those predictors are tested according to the defined evaluation criteria. The prototypical control software architecture designed for HISSTO, the thesis control system, is engineered to provide all necessary functionalities, namely use cases, within the target control domain. The success of this prototype control software is evaluated based on those use cases described in the system requirement elicitation section. This thesis is progressed by the following steps:

Step 1) Outline of contextual knowledge: Chapter 2

Step 2) Identification of the requirements for the prototype system development: Chapter 3

Step 3) Identification and resolution of the prototype system design issues: Chapter 3

Step 4) Detail design of the hybrid prediction models and other system components: Chapter 3

Step 5) Instrumentation, planning, execution, and evaluation of the prototype system: Chapter 4

Step 6) Validation of the thesis hypotheses and the system use cases: Chapter 4

Step 7) Summary of the achievement and future work: Chapter 5

Background

2.1
2.1.1

Building process and its control

Overview
A building has diversified physical processes interacting with each other. The factors being impacted by such phenomena as lighting and thermal process in a building include both human comfort and energy implication. Daylight and electrical lighting can be complimentary in terms of satisfying the required indoor illuminance level. Electrical lighting increases energy consumption whereas daylight is basically free of charge. Both of them increase internal cooling load in summer and decrease heating load in winter. Building envelope components such as walls, windows, and shades interact with outside weather condition and influence indoor thermal condition. Occupants and equipment also have impact on thermal environment by introducing heat and moisture inside. A HVAC (Heating Ventilation & Air Conditioning) system controls temperature, humidity, and air flow which, in turn, influences PMV(Predicted Mean Vote) as the index of thermal comfort. A HVAC system consumes certain amount of energy based on the system type, operation mode and state. There have been significant amount of modeling efforts to describe each physical process in a building as well as the inter-dependencies among various such processes.

From the control point of view, a building is a system which has multi-variant dynamic subsystems showing various linear or mostly non-linear behaviors. Both environmental and occupancy changes in a building increase the complexity of control operations. Occupants not only impose control goals, but also influence various building processes as is shown in Table 2.1. The building factors and the system factors are to be controlled to satisfy occupants requirements under the different states of the natural factors. The building factors are normally determined during design and construction phase of a building life cycle while the states of the system factors are practically decided in the buildings operation phase. Both the natural and the occupancy factors are dynamic but normally not controllable, therefore, the building and the system factors need to be interactively adjusted to these factors.

The control goal of the system factors is to minimize cost while maximizing occupants comfort (i.e. an adequate indoor illuminance level and an acceptable PMV (Predicted Mean Vote)). Build6

ing control normally focuses on the manipulations of the target systems to make up for the gap between the desired state and the current one. Because of the complex inter-dependency of all factors involved in a building process, determining even a single control target system state requires a proper understanding of the interactions among all related factors (Table 2.1) .
Table 2.1: Factors influencing thermal and lighting process in a building Classification Natural factors Thermal process solar insolation, wind, outdoor temperature, humidity Occupancy factors number of occupants, activity type, occupant schedule, clothing Building factors building geometry, orientation, overhang, glazing area, glazing material, wall construction, wall material, interior finish, ceiling & floor materials, room volume, surface area Lighting process solar irradiance, sky condition, ground surface reflectance number of occupants, occupants location, activity type, occupancy schedule site latitude & longitude, building geometry, orientation, overhang, shades, glazing area, glazing reflectance, glazing transmittance, interior finish, interior surface area, interior surface reflectance, interior surface transmittance System factors external shade, internal shade, HVAC system characteristics light redirection louver, blinds, luminaires

2.1.2

Daylight and electrical lighting process

Visual environment in a building is determined by numerous factors. Few performance factors have been used for selection of lighting equipment and its location throughout 1950s, 1960s, and early 1970s (Flynn et al. 1992). Such performance criteria as illuminance level and energy consumption are the typical example of those few factors. Figure 2.1 shows how light interacts with a built environment. For electrical lighting calculation, only direct and indirect internal components are to be considered. The sun is a single source of daylight. There are three components to be considered in daylight calculation:

Sky component: The rays from the sun are partially absorbed and modified by the atmosphere. Incoming sunlight is also diffused by the clouds before reaching a building envelope. Modeling of this modified sunlight by the atmosphere and clouds is normally based on the turbidity applied to the entire sky. Angular relationship between the sun and the target space is another factor creating daily and seasonal variations of the indoor daylight profile. Solar azimuth, solar altitude, and building orientation are, therefore, critical factors influencing this 7

phenomenon. Externally reflected component: The sky component sometimes can directly hit the indoor reference point but part of it is either diffused or reflected by the external objects such as neighboring buildings, ground, or overhang before being introduced to the indoor space. Internally reflected component: Along with the externally reflected component, the internally reflected light component is also important part of indoor illuminance calculation. Surface properties such as transmittance, absorption, reflectance as well as specularity are important to calculate the amount of light bouncing back from a surface. For more precise illuminance calculation, the radiosity method is used for diffuse surfaces whereas the ray tracing is applied to specular surfaces.

Average illuminance can be derived to represent the illuminance of a certain area having multiple illuminance reference points. Uniformity factor is another index to evaluate how evenly illuminance values are distributed throughout a space. Dimming is basically a control scheme to compensate daylight with electrical lighting so that both human comfort and energy saving can be achieved. Glare is another phenomenon which has impact on visual comfort. Glare is caused by unbalanced perception of light on the human retina when there is a significant luminance difference in his/her visual field. Glare can come from either the daylight source or an electrical light source. Especially the glare on a computer monitor is becoming an important factor to be considered as the typical office work evolves toward a computer-supported information processing task. Controlling glare is a non-trivial task because glare is also dependent on such factors as the occupants position and the mode of activities in a space which are normally dynamic in their nature (Li 1997).

Solar radiation brings not just light but heat into the space. This phenomenon has energy implication especially during summer and winter because it increases cooling load in summer and decreases heating load in winter (Reynolds 1992). In daylight responsive lighting control, determining how much daylight should be introduced to the inside is, therefore, a very delicate issue (Mahdavi et al. 1995). There have been many new daylight modification systems introduced to the construction of a building. Device such as light redirection louver is adding more sophistication to our visual environment control capability by turning a traditionally static building facade into a dynamic one. By having this type of device, flexibility in controlling our visual environment can increase significantly even after a building is designed and constructed.

Luminaire

External reflection

Direct component

Internal reflection

Figure 2.1: Daylight and electrical light process in a space

2.1.3

New perspective on building control process

New building systems, components, and assemblies have been introduced along with increasing attention to the innovative concepts for energy conservation and environmental quality. The goal of building operation is to maximize occupants satisfaction while minimizing operational cost. Furthermore, the integration of building systems for an enhanced performance is becoming more and more important to increase user satisfaction, efficiently. In this context, a more intelligent and reliable building control approach is indispensable. DDC (Direct Digital Control) has greatly influenced the overall building control practice by innovating both control hardware and software (Brandt and Shavit 1984). Conventional PID (Proportional, Integral, and derivative) controller is still being widely used, but new approaches using advanced process models or AI (Artificial Intelligence) techniques are now available to control various building processes including thermal, visual, and air flow environment (Jeannette et al. 1998). In recent times, internet-based building monitoring and control systems have been introduced which enable location-independent building operation with proper set of software considering security and various levels of access privilege (So et al. 1998). Neural network, as one of the machine learning techniques, has been used for thermal load prediction and HVAC system control and is sometimes combined with PID controller to enhance its adaptation capability. Four major issues are identified for this research considering the new trends in building control domain:

Extending the number of control criteria beyond the limited traditional ones Enhancing prediction capability of a building control model

Agile and precise adaptation to the environmental and system changes Providing a well-established interaction scheme between users and building control system

2.2
2.2.1

Models for building process control

Simulation model

2.2.1.1 Simulator to support building process control Simulation is the transparent model of a system constructed through examining pertinent objects and processes in the target system. Simulation, as a virtual system, allows one to make system parameter changes and to study their effect without relying on the actual system which is sometimes inaccessible or costly. A model can be gained in a mathematical form describing interactions among its components. Some of the ways to build a process model are discussed as follows:

By acquiring a cross-correlation function out of input and output data and use it to derive one of multiple candidate model forms.

By establishing a model having a core of formulations describing already explained mechanisms in the process followed by numeric manipulations to decide the unknown coefficients.

By using regression method to determine the magnitudes coupled with hypothesized relations. By applying numeric method to fit unknown coefficients to the statistically defined dynamic relations.

The increasing need for more energy-sensitive and adaptive systems for building control has been encouraging the use of more precise and delicate computational models of various building systems. Those computational models are being used to supplement or sometimes even replace costly equipment testing to develop more energy-saving building systems and components. Simulations in real-time helps to build the control logic for complicated building systems to evaluate the apparently explosive number of potential options. The possible outcome of this process could be an option minimizing energy consumption and guaranteeing stable environmental control with reliable equipment at the same time.

In building control domain, on-line simulation models can be used for predicting actual systems dynamic behavior by having input data from the sensors or other sources. Simulation, as the virtual building, can provide an useful tool for generating and evaluating multiple control alternatives based on the given set of preference criteria without being restricted by the constraints that actual 10

building and its systems have.

Contextual data such as the fluctuation of indoor occupancy, exceptional environmental conditions (i.e. lighting), and the level of equipment use can be provided to the simulator to increase its predictive potential. The following techniques are often used to achieve different goals by using simulation as a model for control:

Sensitivity analysis: Identification of control-sensitive variables is important. A series of experiments could be done to achieve this goal by systematically increasing or decreasing a subset of the independent variables, while others remain constant, to observe the impact of such operations.

Goal seeking: In goal seeking, the desired target output of a system should be defined first to identify set of inputs which possibly yield that target output. Special techniques are necessary to get to the desired input because there can be multiple input sets generating the same target output. For example, to satisfy target indoor illuminance level, one can either change the luminaire dimming level or simply manipulate the blind. When a target output is defined, both sensitivity analysis and what-if analysis can help to guide which input set better be modified to produce the target output.

What-if analysis: What-if analysis is to identify the consequence of a certain assumed control action. By setting simulation input values the virtual action, the outputs of the simulation can be analyzed to see the outcome of that assumed action taken as assumption. This process is also useful for system fault detection or for identifying an adaptation strategy when a building component system or the building configuration is changed.

The way of using a system model in an actual control practice is another issue to be explored. Typical feed-forward control (model-based) process as opposed to the feed-back control (sensor-based) process is illustrated in Figure 2.2. Usually, a system model identifies necessary set of inputs to the system by predicting the system outputs with different input sets and comparing them with the target output. This goal-seeking process needs a reasonably precise system model which is an essential part of feed-forward (open-loop) control architecture.

11

a) Feed-forward control process r(t) system model u(t) system y(t)

b) Feed-back control process r(t)

+ -

c(t)

system model

u(t) system

y(t)

sensor
r(t): model input, c(t): calibrated model input, u(t): system input, and y(t): system output Figure 2.2: Feed-forward (a) and feed-back (b) control process

Figure 2.3 shows an example of how an analytical system model such as a simulator can be used for the control purpose. Loop a) is the model calibration cycle by which the simulator is calibrated based on the detected model error. Loop b) is the goal seeking loop by which a sufficiently calibrated simulator is used to identify a proper set of system inputs for generating the given target output. target output

- deviation
b) goal seeking loop input system model model output

control error

a) calibration loop

system

model error

system output

Figure 2.3: Feed-forward control process example

A critical task toward the realization of a simulation-assisted building control system lies in the development of a strategy to create a well-defined set of control options that, together with the projected contextual conditions, serve as the basis for comparative and/or parametric simulation runs. The results of these simulations enable the control system to anticipate the impact of a control action choice on the selected performance indicators. While there may be numerous methods to derive at a structured set of such control options, two principal approaches are briefly described below (Mahdavi and Berberidou 1994): 12

The Generate-and-Test Method (GAT): This method involves the rule-based generation of a finite number of discrete control options. Such options may involve, for example, various positions of a movable external shading device, positions of operable windows, or various on/off timing schemes for intermittent heating/cooling. These schemes are then evaluated and ranked (possibly in view of multiple criteria involving power consumption, cost, emissions, visual and thermal comfort, etc.) based on the results of multiple simulation runs.

The Bi-directional Inference Method (BDI): This method involves the explicit definition of control variables and performance indicators. An example of a control variable would be the position of a moveable external shading and/or light-redirection device, or the deviation of heating/cooling set-point temperature from the space target temperature. Examples of the performance indicators are the average illuminance on a desk surface, illuminance distribution uniformity, annual building energy demand, the average cumulative deviation of the maintained space temperature from the set-point temperature, or the average cumulative PPD (Predicted Percentage of Dissatisfied) in a space. Starting from an initial operational state, the bidirectional inference mechanism facilitates the derivation of required changes in the control variables based on desired changes in the performance indicators. This derivation can be accomplished via the investigative projection technique.

Figure 2.4 illustrates the use of BDI and GAT for simulation-assisted building control.

target perf. attributes

preference processing

virtual building
Bi-Directional Inference (BDI)

control variable attribute

sensing

control
Generate-And-Test (GAT)

rule-based option generator

control schemes matrix

parametric simulation

control scheme selection

Figure 2.4: : Use of BDI and GAT for simulation-assisted building control (Mahadavi 1997b)

13

2.2.1.2 LUMINA as a lighting simulator

To be able to use a simulator as the prediction tool for both daylight and electrical lighting, it must have: building model sky model system model (light redirection louver, shade, luminaire etc.) occupancy model daylight process model electrical light process model

Lighting process model can be coupled with thermal process model to assess the impact of heat gain from solar radiation and luminaires. As a lighting simulation program, LUMINA (Pal and Mahdavi 1999) is capable of modeling both daylight and electrical lighting process even in the spaces having a complex geometry. LUMINA uses both radiosity and ray tracing as its core algorithms. Ray tracing and radiosity based simulation techniques have overcome many of the limitations a simplified table-based hand calculation method has.

The major concerns of the ray tracing or the radiosity based methods are computational storage and time. The computational storage is somewhat more of an issue in the case of radiosity (especially for diffuse surfaces) while the computation time is critical in the case of ray tracing (especially for specular surfaces). Most global illumination simulation techniques may use a combination of radiosity and ray tracing method, making a trade-off between computational storage and computational time (Sillion 1994).

Since most architectural spaces include diffuse surfaces with occasional specular surfaces, a predominantly radiosity-based method which enters into a recursive ray tracing mode whenever a specular surface is encountered is preferred for the development of LUMINA. In a radiosity based algorithm, the most computationally expensive part of the calculation, i.e. the calculation of form factors, needs to be performed just once and these results can be used repeatedly for multiple iterations. A two-pass radiosity algorithm using extended form factors which include ray traced specular transfers is given by Tellier and Bouatouch 1994. This is extended to include transmitting surfaces and is implemented in the following sub-processes (Pal 1999):

14

1. Read internal surfaces from a file. Surface information includes vertex coordinates (x, y, z) for each vertex followed by reflectance, transmittance, diffuseness of reflectance, specularity of reflectance, phong exponent for reflectance, diffuseness of transmittance, specularity of transmittance, and a phong exponent for transmittance.

2. Read external surfaces from a file. The surface information is the same as for internal surfaces.

3. Divide internal and external surfaces into patches by overlaying a grid and determining which grid elements lie inside the surface. A smaller grid is used for internal surfaces and louvers and overhangs. A bigger grid is used for surrounding building surfaces.

4. Read windows and lights. Repeat the process except that lights don't reflect or transmit but have an intensity distribution which is read from IES formatted luminaire files.

5. Divide windows and lights into smaller elements by binary subdivision.

6. Calculate the visibility matrix for internal surface elements.

7. Calculate the visibility matrix for external surface elements.

8. Calculate the extended form factor matrix for external surface elements. The extended form factors use ray-tracing to determine the specular component of the extended form factor.

9. Similarly, calculate the extended form factors for internal surface elements.

10. For each time step of the simulation period:

a) Build the sky luminance distribution using SOLARIS and Perez sky algorithm.

b) Compute the direct component of illuminance on the external surface elements.

c) Compute the radiosity solution for the external surfaces using progressive radiosity.

d) Compute the direct component of daylight and also the initial direct lighting from the electric lights for the internal surface elements. Visibility of window or light patch is taken account. The sky is divided into patches and if a sky patch is obstructed by an external surface element, the lumi-

15

nance of the sky patch is replaced by the luminance of the obstruction. If the obstruction is specular, backward ray tracing is used to compute the specular component of light transfer from the external element to the internal element. The environment is partitioned into exterior and interior spaces. The radiosity solution for the exterior space is calculated first and then its contribution to the interior space is computed. This is more efficient than treating them as one space, since it is easier to solve two smaller systems of equations rather than one large one. This is based on the assumption that the interior space has an insignificant contribution to the exterior space.

e) Compute the radiosity solution for the internal surfaces using progressive radiosity.

Running LUMINA takes about a minute for a normal sized room (1,000 patches). Most of the time needed is taken up by the visibility and extended form factor calculations. Light redirection louver is considered as a dynamic external object having multiple surfaces modifying incoming daylight before it is introduced into the interior space. LUMINA uses Perez model for generating sky conditions necessary for the simulation. Earlier daylight simulation techniques relied on simplified sky models such as the uniform sky, the CIE standard overcast sky, or the clear sky. These have limited applicability for predominantly intermediate skies. With the more advanced sky luminance distribution models available today, the applicability and accuracy of daylight prediction tools are expected to increase. However, most of these models have either been validated for the data from which they are empirically derived or have differential performance results when applied to different climatic conditions (Littlefair 1994). All weather sky model has been developed by Perez et al. (1993) on the basis of sky luminance data collected for predominantly clear skies, this model uses a clearness index and a sky brightness factor to compute the sky luminance distribution (Pal and Mahdavi 1999).

2.2.2

Machine learning model

While simulation involves the explicit description of real systems and their processes, a typical machine learning technique relies on inductive reasoning based on the given data sets. On-going researches show that there are many alternative statistical methods (i.e. high-dimensional non-participant regression methods) available for dealing with data mining tasks with a weaker model and large data sets (Banks et al. 1999) Machine learning technique is capable of on-line learning from the real system operation. A machine learner can be tuned for optimal system operation even in an uncertain and dynamic environment. Most of machine learning modules need training and cannot handle untrained conditions beyond their capability of generalization. Depending on the source of knowledge and the way a machine learner captures it, a machine learning method can be classified as one of the following three categories: 16

Supervised learning: A supervised learner is given both inputs and corresponding outputs so that it can predict right condition-outcome mapping after training. Supervised learning is capable of function approximation and system identification. Supervised learning requires the correct output signal for each input vector to be specified. Neural network is one of the algorithms for implementing this type of learning.

Reinforcement learning: Reinforcement learning is suitable when there is no condition-outcome example to be trained with. Instead, the learner only gets reward (either positive or negative) as a state is changed into another by an action. Reinforcement learning progresses by receiving an implicit scalar evaluation of an action and is capable of policy identification for choosing actions to achieve its goals (Mitchell 1997). This learning scheme achieves its goal through identifying a series of actions that maximize rewards.

Unsupervised learning: Unsupervised learning clusters and characterizes input values without any target output or reward guiding its learning process. An unsupervised learner self-adjusts its parameters and structure to capture the regularities of input vectors without receiving explicit information from the external environment. This self-organizing learning scheme is useful especially when there is no prior knowledge either explicit or implicit except for the data set which only includes inputs. Clustering and discovery are two major application domains of unsupervised learning technique. Clustering attempts to classify objects based on feature descriptions. Discovery learning is more likely to be used in theoretical environment. For example, a program named BACON, as a model of data-driven scientific discovery, discovered a number of scientific laws such as ideal gas theory, Ohms law, and Joules law.

The basic motivation of using machine learning technique is to capture the pattern of dynamic system behaviors (system identification) and to project its knowledge into the near future to predict possible states of a system or a controlled process (parameter estimation). Unlike rule-based systems, machine learning techniques are useful in the control of unidentified complex and dynamic systems by learning directly from the multiple instances of the system input-output mappings called patterns. Machine learning module for a system control has strength especially in the following situations (Narendra 1990):

When a controller is theoretically definable, but too complex for implementation When the controlled process has a poor transient response for initial conditions in a domain of interest. In this case, the identification of the system over a long period of time followed by the use

17

of nonlinear controller is needed When stabilization of a controlled process is needed for the efficient operation of a system at several equilibrium states When a control should be carried out on the basis of output patterns and the state space is partitioned into disjoint regions which are equivalent for purposes of control, therefore, the optimal input corresponding to each region is required

One the advantages of having a machine learner as the major control agent is its adaptation capability to dynamic conditions. When noticeable deviations are expected due to, for example, an incomplete model, adaptive control systems is supposed to compensate through backing-up the model based on the available information. Adaptive control techniques are normally designed to deal with uncertainty in the controlled process. A process model for control can be refined by a certain additional program which observes the behaviors of the control process model in operation. Adaptive system, therefore, is useful in building a controller capable of responsively dealing with a complicated and dynamic environment. Adaptive control allows a control system to observe its own behavior and adjust accordingly, which requires both learning and prediction capabilities.

Neural network is one of the most popular supervised learning techniques. It has been engineered as a computational system modeled after the learning abilities and parallelism of biological nervous systems. The applications of this technique include speech recognizers, explosives detectors, airline seat allocation systems, and loan risk assessors. Neural networks are suitable for non-linear modeling for dynamic system control. They can successfully be integrated with the overall control system. Dynamic systems are generally history-dependent and cannot be modeled by static input-output maps. Therefore, neural network architectures and training techniques for building dynamic models are required.

Neural network learning methods provide a robust approach to approximating real-valued, discrete-valued, and vector-valued target functions. Learning to interpret complex real-world sensor data is one of the best fits of neural network. Neural network is robust to noise in training data (Mitchell 1997). Training time of neural network depends on the number of weights in the network, the number of training examples considered, and the settings of various learning algorithm parameters. Neural network consists of input and output layer and hidden layers in between. Each layer contains nodes and links and those weights associated with the links are to be adjusted to fit the input-output relationships. The backpropogation algorithm is the most common network learning method. Backpropogation searches the space of possible hypotheses using gradient descent to iteratively reduce the error in the network fit to training examples. Gradient descent converges to a local minima in the training error with respect to the

18

network weights. Gradient descent is useful for searching continuously parameterized hypothesis spaces where the training error is a differentiable function of hypothesis parameters. The application of neural network typically comprises two phases. A learning phase and an operation phase. Learning is the process through which neural networks are acquiring the knowledge embedded in the training data. A trained network subsequently represents a static knowledge base which can be recalled during its operation phase. Following is the backpropagation algorithm used for capturing knowledge embedded in training examples (cp. Mitchell 1997):

1. Create a feed-forward network with n in input units, n hidden hidden units, and n out output units 2. Initialize all network weights to small random numbers (i.e. between -0.0.5 and 0.05). 3. Until the termination condition is met, Do For each x, t in training examples, Do propagate the input forward through the network: 3-1. Input the instance x to the network and compute the output o u of every unit u in the network. propagate the errors backward through the network: 3-2. For each network output, calculate its error term k
k ok ( 1 ok ) ( tk o k )

(2.3)

3-3. For each hidden unit number, calculate its error term h
h oh ( 1 oh )

k outputs

kh k

(2.4)

3-4. Update each network weight ji

ji = E d = ( t j o j )o j ( 1 o j )x ji w ji ji = j x ji

for output unit weights

(2.5) (2.6)

for hidden unit weights

Each training example is a pair of the form x, t , where x is the vector of network input values, and t is the vector of target network output values. is the learning rate. o j is the output computed by unit j ,
t j is the target output for unit j . The input from unit i into unit j is denoted x ji , the weight from unit i

to unit j is denoted wji , and the output error is represented as E d .

The capabilities of neural networks in control domain can be summarized as follows (Barto 1990): Copying existing controller: Neural network can be trained from already existing controller, sys-

19

tem model, or a human expert who has knowledge about effective control rules. Adaptive prediction: The input to the neural network consists of delayed values of the signals, and the target output consists of the current values of the signals. The network tries to match the current signal values by adjusting a function of their past values. When the input to the network bypasses the delay units, the output of the network is a prediction of the values the signal will have in the future. System identification: Training information can be obtained by observing the input-output behavior of a system where the network receives the same input as the system, and the system output is the target neural network output. If one selects a class of model to design an effective controller, a control law can be expressed in terms of the parameter estimates produced by the system identification procedure. Identification of system inverse: In this method, the input to a network is the output of the system, and the target output of the neural network is the system input. If the neural network is a system inverse, by feeding desired system output to the neural network, it can predict what the system input should be. For error learning, the input to the neural network should be actual system output and a feedback controller needs to be used during training. Differentiating a model: This method is for training a controller relying on backpropogation between layered neural networks such as forward model (system model) and controller. The propagation of the errors between actual and target system outputs back through the system model generates the error in control signal useful to train another neural network for controller.

20

HISSTO: a hybrid system for environmental control

3.1
3.1.1

Problem identification
Issues in building control models

With the advances in computation and DDC (Direct Digital Control), the model-based building control becomes an attractive option. A model may not always precisely capture the actual system behavior due, in part, to the difficulty of acquiring exact descriptions of building system properties, such as materials and construction features. Some simulation programs are computationally too intensive to be effective for real-time control purpose. An example is a lighting simulator that uses ray tracing in its modeling process. Such simulation programs cannot be used for control purposes unless the control state search space is dramatically reduced. Machine learning can address this problem. However, it often requires large amount of data for training. For instance, before a neural network is trained, or if it encounters unexpected conditions, it is not able to predict accurately (Curtiss 1996). The need for retraining makes it difficult for a machine learner to respond quickly to the system retrofit and/or seasonal weather pattern changes. Its sensor-dependency represents an additional difficulty, especially when placing and/or maintaining sensors are costly or otherwise not desirable. Conventional lighting control systems do not necessarily allow multiple control modes such as manual mode, scheduled mode, and predictive mode. Limited accessibility due to the location-dependency of building systems control also needs to be addressed.

3.1.1.1 Challenges in simulation Accuracy of prediction

Simulation is a generic analytical model for a specific process and can not always describe actual world. In many cases, validation of a simulator based on empirical data is expensive and time-consuming. It is normally pursued at a national or an international level, although many individual research groups undertake small monitoring schemes which focus on specific areas of building performance (Clark 1984). It usually takes much time to build and validate a simulation. Simulation can be used for

21

model-based control, training and testing of other control models (i.e. machine learning), and by generating the pairs of control action and predicted outputs so that the most promising control option can be identified. It also can be used to train or test other control models (i.e. machine learner). The feed-forward (model-based) control scheme requires high resolution system behavior description of the system model. Ultimately, it is only by comparing model predictions with the corresponding results from actual building in operation that a models usefulness as a predictive agent must be ascertained. Unfortunately, this task is difficult due to the lack of comprehensive data relating to the performance of real buildings and the shortcomings inherent in even the most sophisticated technique, which make it difficult to model reality exactly. Commonly encountered problems in validating an energy simulation program are shown in the Table 3.1 (Clark 1984).
Table 3.1: Exemplary challenges in energy simulation validation process Complex process Data validation Monitoring air movement and specifying the results in a form meaningful to modelers On-line validation, organization and management of large data sets in a manner which allows estimation of the data reliability Occupants behavior Ill-understood actions of occupants with regard to window opening, blind operation, and control manipulation Design/construction discrepancy Cost of development Climatic data Cost associated with the data logging system, sensor installation, and quality technical staff Availability of simultaneously recorded climatic data relating to the test site (This is especially problematic with many historical performance data sets.) Instrumentation Necessity to ensure, by constant checking, that all instruments remain as calibrated for the duration of the monitoring period Accurate determination of thermo-physical properties as required by the models

Increased computational load

Some simulation programs are too computation-intensive for real-time or quasi real-time control purpose. A typical example is any simulator using FEM (Finite Element Method) or ray tracing as the primary modeling algorithm. Normally, model predictions and the control decision based on them should be done within a certain time frame. For this reason, those simulation programs demanding heavy computation are not suitable for the control purpose unless the control state search space is dramatically reduced to limit the number of simulation sessions necessary for testing different control options. This problem has been significantly eased by the dramatic increase of available computing power, yet a careful consideration needs to be made when developing of a building product or process model for the control operation demanding heavy computation.

22

3.1.1.2 Challenges in machine learning Data dependency

Machine Learning technique often requires large amount of data for training. For example, neural network training process is normally data-intensive and time consuming even though a trained neural network quickly produces outputs for the given inputs. Also, in case of building configuration or system changes, a machine learning module needs retraining for adaptation. This makes the neural network slow in responding not just during the initial training phase but also when it needs a update through retraining. This problem leads to the following requirements:

1) Provision of seamless transition from the training mode to the operation mode 2) Creation of an algorithm whereby the training occurs with minimum memory requirement 3) Inclusion of a substitute algorithm to generate values for the controller output while the neural network is trained

Sensor dependency

Typical neural networks require the inputs/target outputs to be measured, which makes it inevitably sensor dependent. This sometimes causes problem, especially when placing or maintaining sensors is difficult or costly. There are certain cases no sensor could be placed because it simply doesnt exist. For example, glare in an office environment can not easily be measured because it again is the function of the viewers location and view angle which are dynamic in their nature. This sensor dependency can easily limit the boundary of the adoptable performance criteria by which a desired control option is selected. In fact, lots of control variables in building operation can only be calculated instead of being measured, and this poses problems in using neural networks for control purpose.

23

3.2

Requirement elicitation
HISSTO is a pilot control system applied to an intelligent daylight responsive lighting control task. In general, human comfort and cost minimization are the primary driving forces behind any building systems control efforts. For a successful daylight responsive lighting control, HISSTO must minimize the lighting and thermal energy consumption and maximize occupants visual comfort in the target control zone. Visual comfort in a space is not sufficiently captured just by identifying indoor illuminance distribution, therefore, additional performance indicators need to be introduced. HISSTO makes use of the simulator-assisted machine learner training as well as the machine learner-supported simulator calibration and tuning. HISSTO needs to capture seasonal changes of the sky condition while adapting itself to the changes of building configuration (e.g. spatial retrofit). There are also some non-functional requirements (Bruegge and Dutoit, 1999) for developing HISSTO. Predicting and evaluating the values of the performance indicators for all candidate control options should be done within a certain time frame (i.e. 10 to 15 minutes). It is not feasible to use a large number of sensors in the target space beyond a certain period of data collection. Therefore, the sensors required during HISSTOs operation stage need to be confined to a small number (i.e. one or two).

3.2.1

Functional requirements

3.2.1.1 Visionary scenarios of HISSTO A scenario, as an instance of a use case, is a concrete, focused, informal description of a single feature of the system from the viewpoint of a single actor (Bruegge and Tutoit 1999). A scenario could be one of four types (Carroll 1995). As-is scenarios reflect current situation regarding the current system understood by observing and describing user actions. Visionary scenarios focus on future system to refine ideas on the system needs to be developed. Evaluation scenarios describe user tasks against which the system is to be evaluated. Training scenarios teach users how to use the system. Since developing HISSTO is a greenfield engineering, a new system development effort, which starts form the scratch, elucidating visionary scenarios is the best choice to identify HISSTOs potential requirements. Table 3.2 shows an exemplary set of HISSTOs visionary scenarios describing possible system usages of the different users.

24

Table 3.2: Visionary scenarios of HISSTO ID VS1 Scenario name managerOn Travel Actor instance David: FacilityManager Flow of events 1. David is out of Pittsburgh participating in the COMDEX show in Atlanta. 2. David opens up the web-browser on his laptop computer, connects to HISSTO web interface and be authorized. 3. David presses monitoring button and select ControlZone 1 4. All sensor values and the values of control performance indicators for ControlZone1 are displayed on the screen. 5. David presses stop button and closes the web-browser. 1. While working at her office, Kate notices that on-going lightening distracts ambient light level too often due to the predictive control mode in operation. 2. Kate opens up the web-browser on her desktop computer, connects to HISSTO web interface and be authorized. 3. Kate selects ControlZone 1 and change control mode from predictive to manual. 4. Kate sets a comfortable ambient light level by manipulating luminaire slide bars on the screen. 5. Kate presses exit button and closes the web-browser. 1. Team A members decide to have a brief outdoor picnic. 2. Mark, the team leader, opens up the web-browser on his desktop computer, connects to HISSTO web interface and be authorized. 3. Mark selects ControlZone 1 and changes control mode from predictive to scheduled. 4. HISSTO sets ambient light level and louver angle based on the nonoccupancy schedule. 5. Mark presses exit button and closes the web-browser. 1. Kate comes to her workspace on Sunday to finish the remaining work. 2. Kate opens up the web-browser on her desktop computer, connects to HISSTO web interface and be authorized. 3. Kate selects ControlZone 1 and change control mode from scheduled to predictive. 4. Kate presses exit button and closes the web-browser. 1. David gets a phone call from Mark, the team A leader, notifying that the partitions in their workplace have been reconfigured. 2. David checks out the new partition configuration, connects to HISSTO server interface and be authorized. 3. David selects ControlZone 1 and changes building configuration file according to the new configuration. 4. David presses exit button and terminates the HISSTO server interface. 5. HISSTO updates simulator and machine learner for change adaptation. 1. Julia moves to Kates workspace after the recent work group change. 2. Julia opens up the web-browser on her desktop computer, connects to HISSTO web interface and be authorized. 3. Julia selects ControlZone 1 and change control preference profile based on her personal visual comfort priority. 4. Julia presses exit button and closes the web-browser. 1. David gets a phone call from Mark, the team A leader, about team members complaints on the delayed dimming response in ControlZone1. 2. David connects to HISSTO server interface and be authorized. 3. David selects ControlZone 1 and changes simulation and machine learner training parameters to speed up the control response time. 4. David presses exit button and terminates the HISSTO server interface. 5. HISSTO updates simulator and machine learner for a faster response.

VS2

repeatedLightening

Kate: Occupant

VS3

teamAOnPicnic

Mark: Occupant in team A

VS4

workOnWeekend

Kate: Occupant

VS5

partitionChange

David: FacilityManager

VS6

workspace Re-assignment

Julia: Occupant

VS7

slowLampDimming

David: FacilityManager

25

3.2.1.2 Use cases of HISSTO Use case generalizes all possible scenarios for a given piece of functionality. A use case represents a complete flow of events through the system depicting series of interactions caused by the initiation of the use case (Bruegge and Tutoit, 1999). The following statement are the additional descriptions of the HISSTOs major use cases - initiated by only human actors - illustrated in Table 3.3.

Use case 1: Monitor Building Operation All environment factors, occupant factors, and system factors need to be monitored during building operation. This is not just for providing users with the information on what is happening in their work space, but also for accumulating history data to train machine learner or to calibrate simulation whenever it is necessary. The variables that cant be measured also need to be calculated, displayed, and logged for future reference.

Use case 2: Manual Control: In manual control mode, the control is basically up to the user who is directly operating a louver or luminaires through a well-established interactive control interface. Global optimization should be activated in this mode so that the overall visual environment of a control zone is not dominated by only a subset of the occupants.

Use case 3: Scheduled Control Scheduled control is another operation mode with which a predefined control schedule dictates the systems states at any point of time. For example, luminaires can be scheduled to be all off between 7 PM and 7 AM and maintains the dimming mode for the rest of the day. Louvers can be scheduled separately in such a way that they are in open position early in the morning and late in the afternoon during spring and fall season, always closed in summer, and always open in winter. This scheduled control mode requires the analysis of occupancy patterns, environmental changes throughout a year, and possible impacts of the system state changes.

Use case 4: Predictive Control In predictive control mode, current sky condition is captured by outdoor sensors. Then the selected predictor predicts the possible control outcomes based on different candidate control actions. Those predicted control outcomes are then evaluated according to the defined performance criteria. Eventually, a selected control action is executed to change systems states, accordingly. This process can be repeated based on a fixed time frame until the control mode is changed.

26

Sudden unexpected weather changes (i.e. lightening) should be carefully handled not to distract occupants visual field. This is a temporary condition which normally lasts only for some period of time before getting back to normal. The control system should be able to identify the best control actions for those unexpected situations and maintain the selected control state until the exceptional environmental condition is back to normal. For the future reference, the detected condition and the prescribed action for that need to be recorded.

Use case 5: Update Predictor There are two types of change events upon which the predictor needs update by retraining. Environment change is slower and predictable. The daily and seasonal solar insolation pattern change are mainly due to the relative position and movement of the earth to the sun. Daily solar pattern change is relatively easy to capture because it can be done by including multiple days of either measured or simulated data in the neural network training patterns. For tracking seasonal solar insolation changes, at least monthly on-line retraining with updated data set is necessary for the neural networks used for building systems control. Pure simulator as a predictor doesnt need any of this efforts because it can always deal with any time instance in a year to generate predictions over the outcome of the performance indicators.

When a space layout change, a furniture system rearrangement, or an interior surface finish change occurs, the control system should also be able to adapt itself to the resulting new building configuration. This also needs to be done in cases of system addition, elimination, or replacement. Upon encountering these situations, the control system should update its knowledge on its target environment to reflect those changes while the building operation is maintained until the updated predictor is ready to take the control back under its regulation. If the change is either observed or predicted, a typical feed-forward (model-based) controller using updated simulator can be activated. The simulation, in this case, can predict the impact of such changes even without waiting for the actual control output showing deviations. Such an adaptation is the explicit one in the sense that the change can be traced and be informed to the simulator anytime it occurs. Even when a system fault is detected, this scenario might work as long as the faulty system is identified. In the mean time, the neural networks in a hybrid predictor can always be retrained by using either the simulation generated or the measured data reflecting those changes. The following process is a possible scenario which can handle this situation:

1) Once a system or building configuration change occurs, the Facility Manager changes simulation inputs, accordingly. It is assumed that the change is made explicitly but the impact of it is unknown.

2) While the updated simulator is temporarily regulating control operation, the neural networks used in the current hybrid predictor is in the retraining process by having either the simulator-generated data or

27

the measurement data retrieved after the change.

3) Once the retraining of the neural network is finished, the control system brings the updated hybrid predictor back on for the normal operation.

Use case 6: Set Control Preference A User should be able to modify his/her control preference by assigning different weight to each performance indicator. The weight of a performance indicator is relative to each other and has impact on the selection of the best control option at a given time. Once the user preference profile is changed, the control decisions after the change automatically reflects the users new control preference.

Use case 7: Set Control Parameters Changing parameters for simulation and machine learner training has impact on the performance of each predictor. Whenever HISSTO needs performance tune-up, the modification of those predictor specific parameters can be done. To take this change in effect, the hybrid predictor in command needs retraining after either the simulation or the machine learner parameters are changed.

Figure 3.1 illustrates HISSTOs functional requirements represented as a use case diagram in UML notation. The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing and documenting the artifacts of software systems. The UML was originally derived from the object modeling languages of three leading object-oriented methods: Booch, Object Modeling Technique (OMT) and Object-Oriented Software Engineering (OOSE). UML became the industry standard for modeling objects and components (OMG 1977).

Both an Occupant and a Facility Manager are capable of either monitoring systems control states or changing control preference functions for control customization. They can also trigger any of three control-specific use cases. For example, an Occupant can directly specify desirable control actions in Manual Control mode. Predictive Control use case, as the main focus of the system development, includes Test Control Options and Set Actuator State use case. As a part of data acquisition hardware, Sensor actor participates in data collection. Actuator actor receives the control decision and actuates the corresponding system to change its state, accordingly. Collected data is used for monitoring, simulation, or machine learner training while a specific predictor is engaged in the prediction of control outputs. Based on the control output prediction and current control preference functions, the evaluation of multiple control options need to be done to yield the final control decision.

28

Table 3.3: HISSTOs use cases

ID
UC1

Use case name

Monitor Building Operation

Actor User

Entry/Flow of events/Exit Entry: A User is in his/her work space or in a remote place. 1. The User opens up the web-browser on the computer, connects to HISSTO web interface and be authorized. 2. The User presses monitoring button and selects a control zone to monitor. 3. The current sensor readings and control performance indicators for the selected control zone are displayed on the screen. Exit: The User presses exit button and closes the web-browser. Entry: An Occupant is in his/her work space while the control mode is either the scheduled or the predictive mode. 1. The Occupant opens up the web-browser on his/her desktop computer, connects to HISSTO web interface and be authorized. 2. The Occupant selects a control zone and change control mode from the current one to the manual mode. 3. The Occupant sets comfortable ambient light level by manipulating luminaire slide bars and louver angle knob on the screen. Exit: The Occupant presses exit button and closes the web-browser. Entry: The Facility Manager is either in the work space or in a remote place while the control mode of the target zone is not the scheduled mode. 1. The Facility Manager opens up the web-browser on his/her computer, connects to HISSTO web interface and be authorized. 2. The Facility Manager selects target control zone and changes control mode to the scheduled mode. 3. HISSTO sets ambient light level and the louver angle based on the schedule defined by the FacilityManager. Exit: The Facility Manager presses exit button and closes the web-browser. Entry: A User is in his/her workspace while the current mode of the target zone control is not the predictive control mode. 1. The User opens up the web-browser on her desktop computer, connects to HISSTO web interface and be authorized. 2. The User selects target control zone and change current control mode to the predictive mode. Exit: The User presses exit button and closes the web-browser. Entry: The FacilityManager is informed of a certain building configuration change in a workspace. 1. The FacilityManager checks out the changed building configuration, connects to HISSTO server interface and be authorized. 2. The FacilityManager selects the target control zone and changes building configuration according to the identified new configuration. 3. The FacilityManager presses exit button and terminates the HISSTO server interface. Exit: HISSTO updates the simulator and the machine learner for making change adaptation possible. Entry: An Occupant wants to re-specify his/her control preference. 1. The Occupant opens up the web-browser on his/her desktop computer, connects to HISSTO web interface and be authorized. 2. The Occupant selects target control zone and changes control preference functions and/or the weights of performance indicators based on his/her personal visual comfort priority. Exit: The Occupant presses exit button and closes the web-browser. Entry: The FacilityManager decides to tune-up the predictors for better predictive control performance in the target control zone. 1. The FacilityManager connects to HISSTO server interface and be authorized. 2. The FacilityManager selects the target control zone and changes simulator and machine learner specific parameters for adequate tune-up. 3. The FacilityManager presses exit button and terminates HISSTO server interface. Exit: HISSTO updates the simulator and machine learner to finish tune-up process.

UC2

Manual Control

Occupant

UC3

Scheduled Control

Facility Manager

UC4

Predictive Control

User

UC5

Update Predictors

Facility Manager

UC6

Set Control Preference

Occupant

UC7

Set Control Parameters

Facility Manager

29

<<include>>

User

Monitor Building Operation <<include>> Manual Control <<inc lude>> <<inc lude>>

Get Sensor Value <<extend>>

Sensor

Get Event

<<include>>

Predic tive Control

<<include>>

Set Actuator State

Actuator

<<include>> Occupant Set Control Preference <<include>> Test Control Options

<<include>> Scheduled Control Set Access Previliege Set Schedule

<<include>>

<<include>> Set Control Parameters <<include>> <<extend>> Set Building Configuration Update Predi ctor <<include>>

Generate Performance Predictions <<include>>

Fac il ity Manager

Limit Device State Range

Figure 3.1: Use case diagram of HISSTO: UML notation

3.2.2

Non-Functional requirements
Non-functional requirements of HISSTO describe user-visible aspects of the system that are not related to the systems functional behavior. These include user interface factors, hardware considerations, performance issues, error handling, and security issues (Bruegge and Tutoit 1999). HISSTO has the following non-functional requirements:

30

NFR1) Predictions should be precise enough to make an adequate system state change based on the given control performance indicators. Allowable relative prediction error is within 25 % for any predictor.

NFR2) Evaluation of each control option requires to be agile enough to cover a sufficiently wide range of systems state search space within a limited time window. Preferable time window for a control decision is 10 to 15 minutes. This control time window can be overridden when an exceptional environmental change is detected (i.e. sudden hit of direct sunlight or lightening). The response to this exception needs to be quick and pre-programmed since there is not enough time to go through the normal predictive control process.

NFR3) Number of sensors in operation needs to be minimized to reduce the cost and maintenance effort.

NFR4) The system needs to be remotely accessible while providing necessary security by a tightened authentication and authorization scheme.

NFR5) The system needs to provide a way to accomplish cross-building performance domain evaluation of a candidate control action.

31

3.3
3.3.1

System analysis
Analysis of hybridization
Figure 3.2 shows how HISSTOs model components are combined and related to each other. The focus here is on the virtual building which interacts with a real building and its environment. The virtual building consists of building descriptor, sensor, predictor (a simulator and/or a machine learner), and tester. The predictor receives building description and the real-time sensor values (for measuring environment and systems states) to generate control options and the predicted values of the performance indicators for each of those control options. Hybrid predictors are special type of predictors developed for HISSTO. They use both simulator and machine learner components. Tester evaluates the generated control options to identify the most desirable control action. Virtual building has both independent and dependent variables. For example, sky condition is a typical independent variable whereas indoor illuminance profile is a dependent variable which is determined by the interactions between the environment and the real building including the systems to be controlled. The virtual buildings behavior is more than just a replica of the real building in the sense that it does not only copy the real buildings behavior in a passive way, but also virtually tests and self-regulates systems actions for the purpose of satisfying visual comfort of the occupants with minimized operational cost.

virtual building

building descriptor

predictor simulator machine learner tester actuator

sensor real building environment time system wall window louver dimmer blind

clouds

soalr radiation

Figure 3.2: Structure of a virtual building and its relationship with other entities

32

The actual hybridization process, the main focus of this research, is designed primarily for the predictor. Figure 3.3 demonstrates two distinctive structures of such hybridization process focused on the machine learners role in the hybrid construct.

The type A predictor utilizes the trainer-trainee relationship between a simulator and a machine learner. 1) the simulator generates training patterns to provide prior knowledge for the machine learner, so that a machine learner can have initial training. 2) The magnitude of error between the system output and the trained machine learners prediction can serve as the indicator whether or not the machine learner should be updated by retraining. 3) If any change happens in the environment, the building, or a system, this will likely increase prediction error of the machine learner which triggers simulationassisted retraining process.

The type B predictor is basically targeting a calibrated simulator supported by a simulator-error prediction machine learner. In this scheme, the simulator is the major player in control and the machine learner assists simulation calibration for its better prediction. 1) A machine learner is trained for predicting the simulators prediction error by being trained with simulation error patterns. 2) Every time simulation performs prediction, the machine learner compensates the simulator output based on its own prediction for the possible simulation error. 3) By observing prediction error, the difference between the calibrated simulators prediction and the actual system output, it can be identified when the machine learning-based simulation calibrator needs retraining to reflect the possible change in the environment, the building configuration, or a system.

33

Predictor type A.
measurement

training

prediction

update trigger

simulation sensor training pattern

prediction error machine learner

Predictor type B.
measurement training prediction

update trigger

prediction error -

sensor

simulation simulation error

machine learner

training

operation

calibration

Figure 3.3: Typical hybridization schemes between a simulator and a machine learner

3.3.2

System analysis object model

Figure 3.4 is HISSTO system analysis object model showing the logical structure of the pilot control system to be developed. An User is authorized by the SecurityManager and can access the SystemManager. The SystemManager is the major component regulating most of the systems monitoring/control behaviors. The ControlManager uses the MonitorManager, the PredictorManager, and the EnvironmentDescriptor to come up with a desirable control decision depending on the current ControlStategy. The MonitoringManager accesses Transducers: either Sensors or Actuators, and gets their current states. The PredictorManager creates a Predictor in a combined form of Simulators and MachineLearners. The Simulator or the MachineLearner accesses a View through the EnvironmentDescriptor to have necessary information about a Zone or ZoneComponents. It also gets Sensor or Actuator data through the MonitoringManager. The Tester in the ControManager evaluates possible control options identified by

34

the Predictor based on a defined set of performance indicators. The control decision is then passed to the Commander which actuates the corresponding system for its state change. The EventManager screens exceptional states of the devices and environmental parameters, creates Events, and handles those Events, properly. The CommunicationManager mediates all necessary communications among any subset of the system components. The DatabaseManager handles persistent data requirements within the system boundary. The UserInterfaceManager is responsible for creating and maintaining browsers, windows, and other multi-modal user interfaces across the entire system scope.

Us erInterfac eCom ponent

W indow

S y s tem M anager

G laba lDataMo nitor

Us erInterfac eM anager Us er S ec urity M anager

Databas eM anager Connec tion Databas eTenan t rans a c ti on ControlM anager

Control M onitoringM anager Com m unic ationM anager

ControlS trategy

Comm ande r S c heduledControl M anualControl P redic tiveControl

Devic e Stat e P r edic ti on Tes ter

en s or

A c tuat or

E ventM anager

P redic tionM anager

E nvir onm entDes c ri ptor

E vent

E ve ntHandler

P redic tor

Calibrator

V iew

V iewE lem ent

A lertE vent

ChangeE vent

F ailureE vent

S im ulator

M ac hineLearner

ZoneV iew

Zone Co ntrolV iew

Figure 3.4: System analysis class diagram of HISSTO: UML notation

3.3.3

System sequence model

Figure 3.5 shows the interactions among the key objects in HISSTO. The interactions described in this diagram are order-dependent, for example, a certain interaction is either prior or posterior to the other. The diagram depicts: a) a typical sensor value monitoring process, b) an event detection and notification process, c) the predictor update process triggered by a building configuration change event, d) and a typical daylight responsive lighting control process based on a hybrid predictor using a combined lighting simulator and machine learner.

35

Occupant: User

Bro wser: UserInterface

DatabaseManager

SkySensor: Sensor

ZoneView: Vi ew

Lu mi na : Simulator

WF1CNN: MachineLearner

LouverControl: Control

EventManager

LouverAc Actua

selectMon itoring() *requestSensorVal() saveSensorVal() *getSensorVal() displaySensorVal()

a.
requestEventReport() requestState() sendState() detectEvent() saveEvent() sendEvent() di aplayEvent()

b.
detectBldgChange()

editView()

updateView() saveUpdatedView() e tView() *performSimulation() saveResult()

*getT ra in ingPat ten () performTraining() notifyChange() saveWe ights()

c.

displayChange() activateControl() startPredictiveControl() *getSensor() get Traine dNNWeig hts() createNN() getState() performPrediction() getResult() evaluateLouverOptions()

rquestV ie w() cre at eV ie w()

bui ldLight in gS imul at or() e tView() performLightSi mulation() returnResul t() evaluateControlOptions() setState()

notifyChange() di splaySy s emStat e t

logControlHistory()

d.
Figure 3.5: Sequence diagram illustrating interactions among the key objects in HISSTO: UML notation

36

3.3.4

User interface mock-up

HISSTOs overall structure is based on the thin-client-thick-server architecture. The web-based user interface components on the client side have two types of windows: the Monitoring Window and the Control Window. As shown in Figure 3.6, the Monitoring Window has a real-time video display section to deliver visual information about what is happening in the target control zone. An user can specify the control zone he/she wants to monitor, monitoring schedule, and data sampling rate along with the integration time interval of the sampled sensor values. The other sections include the sub-windows for displaying outdoor daylight condition, indoor illuminance distribution, and real-time values of the defined control performance indicators based on the deployed control actions as well as the given evaluation algorithm.

Figure 3.6: HISSTOs Monitoring Window on the web

37

Figure 3.7 shows a design of HISSTOs Control Window on the web. To be authorized for certain control actions, a user is required to input user ID, password, and the target system he/she wants to control. Depending on the users access privilege, control mode and schedule can be selected. Another section of the Control Window allows automation agent setup. For a simulator, building surface discretization level, the louver position change interval, and the luminaire dimming change interval can be specified. For a machine learner, maximum training steps, learning rate, momentum as well as the maximum prediction error could be specified along with the type of machine learner to be deployed. System Control Station section includes user interface elements for manually controlling the louvers and the luminaires in the target control zone.

Figure 3.7: HISSTOs Control Window on the web

38

3.4
3.4.1

System design
System architecture
HISSTOs system design is conceptually based on the object-oriented modeling and design methodology (Rumbaugh et al. 1995) along with the UML (Unified Modeling Language) representation (OMG 1997). OWL project (Bruegge B. et al. 1996) provided useful resources to structure HISSTOs system framework. Figure 3.8 describes HISSTOs system software architecture. In HISSTO, there are nine subsystems such as SystemManager, EnvironmentDescriptor, MonitoringManager, EventManager, PredictionManager, ControlManager, DatabaseManager, CommunicationManager, and UserInterfaceManager. The SystemManager regulates user access privileges while globally managing the system operations in the way it can avoid potential conflicts. The EnvironementDescriptor in HISSTO assembles a necessary building product model on-demand which typically includes a ControlZone with multiple ControlZoneComponents serving as the inputs to the simulator. The MonitoringManager polls sensors and actuators and creates exceptions when the captured state of a device shows an abnormality. The EventManager generates and handles various events, then notifies those events to the observers. The PredictionManager builds a proper predictor and performs predictions on the possible outcomes of candidate control options. ControlManager performs control tasks based on the performance predictions and evaluations of the selected control options. The DatabaseManager provides a single database interface for various data transactions involving all persistent data types for the system. The CommunicationManager primarily controls most of the communications among HISSTOs subsystems either locally or in a remotely distributed context. Finally, the UserInterfaceManager is responsible for creating and maintaining multiple instances of UserInterfaces across the system boundary.

There are other system components connected to the core of HISSTO making it fully realize a distributed building control system. The Hardware/SoftwareInterface provides a bridge to the BuildingMonitoringControlHardware which contains Sensors and Actuators and communicates with HISSTO for data exchanges. In terms of implementation, this communication is achieved through library function calls (HISSTOs core package is complied as a DLL: Dynamic Link Library). HISSTOLocalInterface is mainly for the Facility Manager to perform necessary system monitoring and operation tasks. The HISSTORemoteCommunicationServer is designed primarily for the web-based system operations and has two sub-components: the DataSocketServer and the WebServer. The DataSocketServer sends or receives run-time data across remote processes. For example, sensor values captured through the Hardware/SoftwareInterface can be posted on the DataSocketServer so that the monitoring user interface elements such as ActiveXTM controls, loaded on a remote web browser can pull the values and display them on the screen. The WebServer is to publish HTML files in which various ActiveX controls are embed-

39

ded. The HISSTOWebInterface is a remote client accessing the system through the web and has two types of user interfaces. The MonitoringWebInterface provides current systems states browsing whereas the ControlWebInterface is used for remotely changing systems states or various control parameters.

Hardware/Software Interface Building Monitoring/Control Hardware Sensor Act uator ignal rocessor A/D Converter

HISSTOLocalInt erface HISSTODatabase Control Interfac e Monitoring Interface

HISSTO ontrol anager Environment Descriptor Database Manager

HISSTORemoteCommunicationServer Event Manager Communication Manager Datasocket Server eb erver

System Manager Prediction Manager

UserInterface Manager

Monitoring Manager HISSTOWebInterface WebBrowser ActiveX Control HTML

Figure 3.8: Component diagram describing HISSTOs system architecture: UML notation

3.4.2

System component design

The system analysis object model is further developed to accommodate various system design decisions. The major focus of this task is to increase the system modularity and extensibility. Decoupling implementations-specific products or processes from the generic representation is useful to enhance system modularity. Since HISSTO needs to handle more than one control zone in possibly different control domains, the entire object hierarchy is organized into generic model components, which could be flexibly adapted to the various control situations possibly demanding flexible system extensions. In the system modeling process, software design patterns (Gamma et al. 1995) are widely used to provide reusable modular solutions for organizing various system software components.

40

Every subsystem in HISSTO has its own API (Application Programming Interface) designed as the combination of the Singleton pattern and the Facade pattern. Singleton pattern ensures a class only have one instance allowing a global point of access to it. The Facade pattern defines a unified higher level interface to a set of interfaces, which makes the subsystem easier to use (Gamma et al. 1995). This highest-level interface makes it easier to modularize the system and to simplify the use and maintenance of each subsystems services. For the necessary interactions among subsystems, bi-directional associations are established between the CommunicationManager and any of the other subsystems as is described in Figure 3.9.
SystemManager

UserInterfaceManager

Co ntrolMan ager

Database Ma nager

CommunicationManager

Environment Descriptor

MonitoringManager

PredictionManager

EventManager

Figure 3.9: Top level logical model describing HISSTOs subsystem breakdown: UML notation

The SystemManager component (Figure 3.10) is designed in a Singleton pattern so that the only one global system instance is activated and maintained across potentially multiple instances of control/monitoring operations at any point of time. This is important especially to guarantee that all control actions are monitored and regulated on a globally optimized basis while maintaining tight system security.

Every User needs to be authenticated and authorized before accessing the SystemManager object services. This control of access is achieved through the SecurityManagerInterface by checking an users personal information. Other methods of the SystemManager include the initialization of device control

41

actions, monitoring current systems states on the global level as well as resolving potential or detected conflicts among different threads of control actions.

SystemManager <<static>> _instance : SystemManager* communicationManager : CommunicationManager* userInterfaceManager : UserInterfaceManager* databaseManager : DatabaseManager* monitoringManager : MonitoringManager* eventManager : EventManager* predictionManager : PredictionManager* environmentDescriptor : EnviromentDescriptor* controlManager : ControlManager* 1 <<static>> instance() getSubSystem() controlSystemAccess() initializeSystemOperation() performSystemOperation() terminateSystemOperation() detectConflictEvent() resolveConflictEvent() performDeviceControl() performMonitoring() monitoringGlobalData() 1 1

1..n ConflictResolver 1..n

1 GlobalConflictTable addItem () reso lveConfl ict () rem oveItem () 1

1..n User name : String password : String ip_address : String accessLevel : Interger 1..n logOn() operateSystem() logOut() 1 1 1 SecurityManagerInterface <<virtual>> authenticate() <<virtual>> authorize() <<virtual>> editAccessList() 1 GlobalDataMonitor globalData getGlobalData() detectConflict()

1 SecurityManager Occupant FacilityMa nager se tA ccessPrevil iege () checkGl obal Da ta() checkAccessList() authenticate() 1 authorize() editAccessList() AccessList add() delete() update()

1..n

Figure 3.10: Logical model of HISSTOs SystemManager component: UML notation

The EnvironmentDescriptor subsystem in HISSTO (Figure 3.11) primarily creates a building product model serving mainly as a part of the Simulators input data. The Builder design pattern used in this subsystem separates the construction of a complex object from its representation so that the same construction process can create different representations (Gamma et al. 1995). By constructing Views in an ad-hoc based manner, multiple control actions having different target systems or control zones can share a significant portion of otherwise redundant data. Before performing necessary simulations, a

42

View object describing the target control Zone or the ZoneComponents can be built on demand through the Builder design pattern. A Zone could be either a Site, a Building, a Space, or multiple Spaces. A Site can contain multiple Buildings as a Building consists of multiple Spaces. A ZoneComponent is either, an Occupant, a System, an Equipment, a FurnitureElement, or a Partition. A View is defined as the aggregation of ZoneComponents. Sometimes, a control operation focuses on a ZoneComponent rather than a Zone representing aggregated spaces potentially up to an entire building. If a Zone has multiple spaces in it, this is described by a Composite design pattern, so is a Partition having Doors or Openings on it. Throughout all levels of aggregations, a View object can have ViewElements such as Schedule, Geometry, Sensor, or Actuator objects. Any View object can become a dynamic entity by being attaching a subset of those elements, especially Sensors and Actuators, whenever it is necessary.

EnvironmentDescriptor <<static>> _instance : EnvironmentDescriptor* communicationManager : CommunicationManager* systemManager : SystemManager* databaseManager : DatabaseManager* monitoringManager : MonitoringManager* eventManager : EventManager* controlManager : ControlManager* predictionManager : PredictionManager* userInterfaceManager : UserInterfaceManager* <<static>> instance() registerToT heSystem() getSubSystem() createView() updateView() deleteView() 1 0..n ViewBuildDirector 1 constructView()

ViewBuilderInterface <<virtual>> buildView() 1

View ViewBuilder currentView : View* buildView() getView() 1 1..n vie wT ype : String vie wList : Int eger* atta chVi ewElem ent() dett ach ViewElement () upd ate ViewElement () 1 1..n ViewElement viewElementID : Integer

Schedule setSc hedul e() getSc hedul e() cha ngeSche dule ()

Geometry setGeometry() getGeometry() changeGeometry()

Actuator setValue : Double setValue() getValue() accept()

ZoneView zo neID : In tege r zo neType : String zo neCo mp onentList : ZoneCom pone ntV iew* 1

ZoneComponentView zoneComponentID : Integer zoneComponentT ype : String Opening 0..n

Sen sor value : Double getValue() accept() 1..n

0..n

0..n Site 1 0.. n Building 1 1..n Space 1 Occupant System Equipment Furniture

1 Partition 1 0..n 1 AD_Converter

Figure 3.11: Logical model of HISSTOs EnvironmentDescriptor component: UML notation

43

The MonitoringManager subsystem in HISSTO (Figure 3.12) is to monitor the states of Sensors and Actuators by using the Visitor design pattern. The Visitor design pattern represents the operations to be performed on the elements of a View object structure. With the Visitor pattern, defining a new operation is possible without changing the classes of the View elements on which it operates (Gamma et al. 1995). While traversing down through the TargetView object hierarchy, the Visitor pattern activates the activation of those operations designed for detecting device state as well as any abnormality on a TargetElement. Once the entire detection process is completed, each Visitor object creates a DeviceStateTable or an ExceptionTable to be passed to the other subsystems such as the EventManager or the PredictionManager.

DeviceSateTable MonitoringManager <<static>> _instance : MonitoringManager* communicationManager : CommunicationManager* systemManager : SystemManager* userInterfaceManager : UserInterfaceManager* eventManager : EventManager* environmentDescriptor : EnvironmentDescriptor* predictionManager : PredictionManager* <<static>> instance() registerToTheSystem() getSubSystem() getTargetView() monitorException() monitorDeviceState() notifyResult() 1 0..n ExceptionTable addException() removeException() 1 detectEvent() ExceptionDetectionVisit or iterationPeriod : Integer 1 visitSensor() visitActuator() createExceptionTable() 1..n visitSensor() visitActuator() createDeviceStateTable() DeviceStateVisitor iterationPeriod : Integer 1 setDeviceState() getDeviceState() 1 1 0..n DeviceVisitor <<virtual>> visitSensor() <<virtual>> visitActuator()

0.. n TargetView 1 1 .. n TargetElement <<virtu al> > ac cept()

Sensor value : Double getValue() accept() 0.. n 1

Actuator setVa lue : Doubl e setVa lue() getVa lue () accep t()

Figure 3.12: Logical model of HISSTOs MonitoringManager component: UML notation

The EventManager subsystem in HISSTO is responsible for creating, handling, and disseminating events within the system boundary (Figure 3.13). An Event object is created by referencing the ExceptionTable generated by the MonitoringManager. Once an Event is identified, it is handled by an

44

EventHandler object the process of which is regulated by the Chain of Responsibility design pattern. This design is to avoid coupling an Event to its handler by giving more than one EventHandler object a chance to handle that Event through chaining the EventHandlers and pass the Event along the chain until an EventHandler handles it (Gamma et al. 1995). Based on its characteristics, an Event can be classified as an AlertEvent, a ChangeEvent, or a FailureEvent. Event notification process in HISSTO is designed in the Observer pattern which defines one-to-many dependency between the Event and the EventObserver objects so that when one Event object changes state, all its EventObservers are notified and updated automatically (Gamma et al. 1995). Every Event detected and handled is logged and saved in the database for future reference.

EventM anager <<static>> _instance : EventM anager* com m uni cationM anager : Com m uni cati onM anager* system M anager : System M anager* userInterfaceM anager : UserInterfaceM anager* databaseM anager : DatabaseM anager* m onitoringM anager : M onitoringM anager* environm entDescriptor : Environm entDescri ptor* 1 <<static>> i nstance() registerT oT heSystem () getSubSystem () generateEvent() handl eEvent() notifyEvent() updateObserver() logEvent() 1 1

1 EventLog 1 1 1

0..n EventRecord

1 1 Excepti onT able addExcept ion() rem ov eExc ept ion() detect Even t() 1 EventHandler Gl obalEv entHandler

0.. n Ev entO bse rverInterf ace <<virtual>> update() 1 1

0..n Event eventSourceState : Double 1..n attach() dettach() notify() handl eEvent()

<<vi rtual>> handleEvent()

Al ertEventHandler handleEvent() EventObserver observerState : Double update() 1.. n 1 Al ertEvent alertEv entCode : St ring getEve ntSource Stat e() setEven tSource Stat e() Change Event changeEventCode : String 1 getEventSourceState() setEventSourceState()

ChangeEventHandler handl eEven t()

FailureEventHandler handleEvent()

1..n

Fa il ureEvent fail ureEventCode : String 1 getEventSourceState() setEventSourceState()

Figure 3.13: Logical model of HISSTOs EventManager component: UML notation

45

Figure 3.14 shows a typical sequence of interactions among participating objects in HISSTOs event generation and handling process. The design of this process is based on the Exception Monitor pattern dealing with exceptions within the scope of an individual collaboration (Douglass 1999).

MonitoringManager

LouverActuator: Actuator

AlertEvent: Event

EventManager

AlertEventHandler: EventHandler

AlertEventLog: EventLog

AlertEventObserver: EventObserver

requestState() reportState() checkState()

createException() createEvent() identifyHandler()

handleEvent() checkMemory() checkSens or() confirm() confirm() createLog() notifyEvent() getEventState() update()

Figure 3.14: Sequence diagram showing HISSTOs event handling process: UML notation

The PredictionManager subsystem in HISST (Figure 3.15) provides an interface for assembling the Predictors and performing predictions for the control outputs needed to evaluate various candidate control options. A Predictor can be composed of multiple PredictorComponents such as Simulators and MachineLearners collaborating based on a specific hybridization scheme. The Builder design pattern is used to structure the Predictor creation process. The Simulator in HISSTO currently is focused on the lighting domain, but it can be the other domains as well depending on the control target devices and systems. For the implementation of the MachineLearner, HISSTO uses NeuralNetworks which need training after being created but before it is activated for the actual prediction tasks. Both the Simulator and the MachineLearner are internally using procedure calls, there is no need to distribute inter-task calls for those objects. The design of the PredictionManager in HISSTO allows dynamic assemblies of the PredcitorComponents and their services depending on the control request within various contexts in a building.

46

PredictionManager <<static>> _instance : PredictionManager* communicationManager : CommunicationManager* systemManager : SystemManager* userInterfaceManager : UserInterfaceManager* databaseManager : DatabaseManager* monitorManager : MonitorManager* environmentDescriptor : EnvironmentDescriptor* <<static>> instance() registerToThe System() getSubSystem() getSimulator() getView() getMachineLearnerTrainingPattern() buildPredictor() updatePredictor() performPrediction() 1 SimulatorInput 1 0..n Predictor 1 PredictorDirector predictorID : Integer constructPredictorComponent() 1 MachineLearnerTrainer machineLearnerTrainerID : Integer getTrainingPatterns() peformTraining() saveTrainedMachineLearner() 1 assemblePredictor() runPredictor() calibratePrediction() 1 1 1..n PredictorComponentBuilder predictorComponentID : Integer <<virtual>> buildPredictorComponent() 1 0..n Simulator 1 predictorID : Integer 1.. n 1 1 PredictorInput 1

Machi neLea rnerInput 1 Calibrator

0..n

MachineLearner 1.. n

1 Si mula torBuil der buildPredictorComponent() 0..n getResult() MachinLearnerBuilder buildPredictorComponent() getResult()

1..n

1 NeuralNetwork Encoder Lighti ngS im ul atorB uiler EnergySim ula torB uilder AirFlowSimulatorBuilder 1 1 compute() learn() 1 n Training Pat tern 1 1..n Layer 1 1.. n Node 1

ThermalSimulatorBuilder

Ac oust icS im ul atorB ui ld er

1..n Link we ight : Do uble updat eWeig ht()

Figure 3.15: Logical model of HISSTOs PredictionManager component: UML notation

47

The ControlManager subsystem in HISSTO (Figure 3.16) prepares and performs the actual control operations. Different courses of a control action are provided based on the Strategy design pattern which defines a family of the ControlStrategies and make them interchangeable (Gamma et al. 1995). This Strategy pattern lets the control algorithm vary independently from clients that use it. Each ControlStrategy is also a Facade so that the complex implementation details can be encapsulated. For example, the PredictiveControl object triggers a series of actions involving the Predictor, the Tester, and the Commander objects. The way a ControlCommand is carried out in HISSTO is organized through the Command design pattern which encapsulates a control request as an object in order to parameterize clients with different requests, queue or log requests, and support undoable operations (Gamma et al 1995).

ControlManager <<static>> cotrolManager : ControlManager* communicationManager : CommunicationManager* monitoringManager : MonitoringManager* eventManager : EventManager* environmentDescriptor : EnvironmentDescriptor* predictionManager : PredictionManager* databaseManager : DatabaseManager* systemManager : SystemManager* userInterfaceManager : UserInterfaceManager* <<static>> Instance() registerToTheSystem() getSubSystem() getTransducer() getControlZoneView() getPredictor() getWeatherData() getUserPreference() createControl() logControlHistory() 1 Con trolLog 1 0..n Control control_ID : Integer selectControlMode() performControl() 1 createControlLog() 1 0..n ControlStrategy 1 <<virtual>> issueCommand() 1 0..n

Inv oker 1..n 1

Device Actuator 1 1 deviceID : integer actuateDevice() reportDeviceStateChange() 1..n 1 Co mm and er executeControl()

0..n ControlCommand <<virtual>> execute()

DeviceControl Command state : String execute()

Ma nualCon trol getUse rInput() issu eCo mm and ()

PredictiveControl performPrediction() testControlOption() issueCommand() 1 1 1..n 1..n

ScheduledControl identifySchedule() IssueCommand()

1..n

Prediction predictControlOutcome()

Tester testControlOp tions() 1

1 TestAlgorithm runTestAlgorithm()

Figure 3.16: Logical model of HISSTOs ControlManager component: UML notation

48

The DatabaseManager subsystem in HISSTO (Figure 3.17) provides a single interface for all data transactions invoked by the persistent data storage requests. This subsystem maintains concurrency and consistency throughout global or domain-specific data operations on multiple DatabaseTenants within a distributed environment. The Transaction object in this model is created by the DatabaseManager and has only a limited lifetime until it commits or rolls back after performing the requested data operations.

DatabaseManager <<static>> _instance : DatabaseManager* communicationManager : CommunicationManager* systemManager : SystemManager* userInterfaceManager : UserInterfaceManager* monitoringManager : MonitoringManager* eventManager : EventManager* environmentDescriptor : EnvironmentDescriptor* controlManager : ControlManager* predictionManager : PredictionManager* <<static>> instance() registerToThe System() getSubSystem() createTransaction() terminateTransaction() 1

0..n Transaction transactionID : Long state : String save() delete() update() query() 1 1..n DatabaseTenant dataHandle : Long getData() setData() searchData()

UserPrefere nce Data

TransducerData

Machi neLearner TrainingPattern

WeatherData

ControlSchedule

En viron me ntDesc ri ption Dat a

ControlHistoryLog

Neural Network ei ght Da ta

EventLog

Figure 3.17: Logical model of HISSTOs DatabaseManager component: UML notation

The CommunicationManager subsystem deals with messaging and data exchange services among HISSTOs components (Figure 3.18). A Connection object is created when a communication request is issued and the parties participating in the communication are identified. Depending on the actual distribution of all connection parties, a Connection is handled either in a remote mode or in a local mode. Every Connection has one of three different stages at a give point of time, namely, CommunicationEstablished, CommunicationListen, and CommunicationClosed. The Strategy design pattern used

49

here allows the Connection object to alter its behavior when its internal state changes (Gamma et al 1995). This design of the CommunicationManager is motivated to keep the system flexible in dealing with both distributed and central system integration scheme.

Co mm uni cationManage r <<static>> _instance : CommunicationManager* systemManager : SystemManager* controlManager : ControlManager* environmentDescriptor : EnvironmentDescriptor* predictionManager : PredictionManager* eventManager : EventManager* monitoringManager : MonitoringManager* databaseManager : DatabaseManger* userInterfaceManager : UserInterfaceManager* <<static>> instance() registerToT heSystem() getSubSystem() identifyCommunicationParties() createConnection() monitorConnection() terminateConnection() 1

0..n Connection connection_ID : Integer connectionState : Integer connect() monitor() disconnect() 1 1 ConnectionImpl 1 1 CommunicationState <<virtual>> open() <<virtual>> close() <<virtual>> acknowledge()

RemoteConnectionImpl

LocalConnectionImpl 1 1 MessagingImpl Communication Established open() close() acknowledge() Communication Listen open() close() acknowledge() Communication l osed open() close() acknowledge()

TCPConnectionImpl

Figure 3.18: Logical model of HISSTOs CommunicationManager component: UML notation

The UserInterfaceManager subsystem in HISSTO (Figure 3.19) provides multiple ways of constructing interfaces mainly to monitor and control building systems states for different types of users. The key element in this subsystem is the Window object which is composed of multiple UserInterfaceComponents such as Buttons, EditBoxes, and SlideBars. The Composite design pattern is useful in organizing objects into a tree structure to represent part-whole hierarchy. This pattern lets the UserInterfaceManager treat individual Window objects and compositions of Windows uniformly (Gamma et al 1995). A

50

Window object can be either a BrowserWindow or an EditWindow depending on the use case it is supposed to satisfy. There can be nested Windows as is indicated by the Composite design pattern. Assembling Windows on-demand is a useful strategy when the system needs heterogeneous user interfaces varying dynamically based on the types of interactions in different contexts. The UserInterfaceManager detects various user interface events derived from the systems use case model. Depending on the characteristics of the detected event, UserInterfaceManager activates/deactivates corresponding methods on the pertinent UserInterfaceComponents. Each UserInterfaceComponent is responsible for displaying or receiving information necessary for the system functionality.

UserInterfaceManager <<static>> _instance : UserInterfaceManager* communicationManager : CommunicationManager* systemManager : SystemManager* databaseManager : DatabaseManager* monitoringManager : MonitoringManager* eventManager : EventManager* predictionManager : PredictionManager* environmentDescriptor : EnvironmentDescriptor* controlManager : ControlManager* <<static>> instance() registerToTheSystem() getSubSystem() createUserInterface() getUserInput() displaySensorVal() displayEvent() deleteUserInterface() 1

Coordinate x : Integer y : Integer width : Integr height : Integer 1

1..n Window windowID : Integer zoom : Integer assembleWindow() displayWindow() updateWindow() deleteWindow() resizeWindow() 1

1 UserInterfaceComponent uiComponentID : Integer create() update() delete() display()

0.. n

1..n

Bro wse rWi ndow getData()

EditorWindow setData()

Button

ComboBox

Kno b

SlideBar

Chart

EditBox

ListBox

ScrollBar

EventBrowserWindow

Figure 3.19: Logical model of HISSTOs UserInterfaceManager component: UML notation

51

3.4.3

Concurrency identification
Concurrency is one of the most important design considerations for HISSTOs system development. At any given time, there are at least five threads running. The SystemManager, the MonitoringManager, the EventManager, the CommunicationManager, and the UseInterfaceManagher must have separate threads so that they can run concurrently. For example, HISSTO must collect sky condition data while performing event detection process allowing users to monitor the current systems states. The SystemManager, the CommunicationManager, and the UserInterfaceManager subsystem are always activated. The ControlManager subsystem should be able to handle multiple control requests concurrently each of which can be in one of those five states: training, prediction, test, actuation or idling. If training is necessary to update a selected Predictor, a separate thread should be given to this training process while maintaining control operation in a different mode. For this reason, multi-threading is absolutely required for this system to guarantee desired system operation. Considering potentially multiple computation-intensive processes at a given time, CPU and memory management are crucial for a successful system operation. There should be careful software design to handle potential computational overload. The tactics for this are:

Reducing computational load whenever it is possible Reducing concurrency by activating computation intensive processes in a serial fashion rather than in parallel one unless it is absolutely necessary

Use of multi-threading when concurrency is inevitable

To avoid conflicting concurrency which eventually should be globally regulated, only a single on-going global control instance is allowed to be activated and all other localized controls are multi-threaded from it.

3.4.4

Hardware/software mapping
Eventually, Occupants and Facility Manager are expected to interact with HISSTO through the internet which provides a platform-independent remote access. Most data acquisition or control devices come with hardware plus software designed to be operated on either a PC or an UNIX machine. So, at the instrumentation level, there certainly are hardware/software dependencies. The entire MonitoringManager subsystem is designed to decouple the system from vendor-specific Sensors or Actuators so that HISSTO can have flexibility and extensibility for potential infrastructure changes. In the PredictorManager, the Simulator and the Machine Learner are all portable as long as the operating system supports C/

52

C++ compilation. Considering cost, performance, and compatibility, the PC is a desirable choice as the target platform for HISSTO. In terms of performance issue, the overall system performance is influenced by many factors. The sampling rate of data acquisition, the size of machine learner training patterns and steps, and the number of simulation sessions for prediction are all contributing factors to the system performance. Data acquisition, machine learner training, and simulations are all memory intensive tasks, therefore, reducing computational load for each job and minimizing concurrency for those tasks are absolutely necessary. For the same reason, allocating a high performance CPU for those tasks is also critical.

For HISSTOs local interface, the software/hardware integration is made by using LabviewTM programming environment. This development environment uses a graphical programming (G programmingTM) technique which allows a programmer to drag/drop and connect graphical symbols representing specific programming elements. A VITM (Virtual Instrument) is an unit program component which can be a collection of other VIs. Each VI has a front panel and a source code editor with which a programmer can build code and user interface, simultaneously. The MonitorVI and the ControlVI can receive/send signals through a PC board or a serial port on the computer from/to the transducers such as the louver, the dimmers, and the light sensors. Each VI accomplishes the connection to the core of HISSTO written in C/C++ through the library calls to the program compiled in DLL (Dynamic Link Library) form.

The UseInterface for HISSTO is designed to monitor the sensor values and to actuate the target systems from an web browser. This is a "location-independent cross-platform" solution with a proper security provided. To make this possible, ActiveXTM technology combined with Data socketTM communication is used. There can be another way of achieving this such as the combination of JAVATM and CORBATM technology enabling web-based monitoring and control as is demonstrated in the OWL project (Bruegge and Dutoit 1999). HISSTOs dependency on the ActiveX technology is imposed by the Labview programming environment responsible for performing most of the instrumentation tasks. Both MonitorVI and ControlVI maintain connections to the client side ActiveX controls embedded in the HTML documents and loaded from an ActiveX container such as MicroSoft ExplorerTM web browser. The necessary communications between the remote ActiveX controls and the remaining HISSTO subsystems is done by the WebServer (for publishing HTML files) and DataSocketServer (for bi-directional remote information exchanges). Figure 3.20 illustrates the topological structure of HISSTOs hardware components and Figure 3.21 shows the physical connectivity of HISSTOs instrumentation within a real building.

53

HISSTOClient

HISSTOServer

manual Listen To Events Issue Commands

executive Poll Sensors Evaluate Control Options Generate Control Commands Publish Device States Listen To User Inputs

A/D Converter

nonpreemptive

Sensor

Actuator

Convert A-D Convert D-A Process Signal

Louver

Luminaire

Figure 3.20: Deployment diagram describing HISSTOs hardware topology: UML notation

Daylight Station RS-232 Louver controller M Data

Ballast

PC W/S AT-MIO/AI E board

Analog signal

Photometric Sensors

Figure 3.21: Physical connectivity for HISSTOs system instrumentation

3.4.5

Data management
Data management in HISSTO is important because the system is heavily dependent on the various forms of data. HISSTO will be likely to generate and handle a significant amount of persistent data. Persistent data is any data which maintains its state across system reboot. This includes sensor data which

54

is kept for months, if not years. Other persistent data includes simulation inputs and outputs since this data can be used for machine learner training purpose. The system builds a number of volatile and temporary data stores. For example, predictions done by a simulator or a hybrid predictor for each control interval are temporal so is the evaluation result of each control option based on the performance indicators and preference functions. Depending on the sampling rate, multiple sensor readings need to be buffered before being processed for obtaining useful sensor data. A final category of data can be characterized as semi-persistent data. This data is persistent in its nature but is not guaranteed as such. An example of this is the weight value for each link in neural network which should be maintained for the initialization of a specific neural network until it has to be updated.

3.4.6

Global resources management

Security issue in HISSTO is critical especially for protecting the system from non-authorized users. This is a common concern for any web-based information system development. Each sensing or actuation device also should be given a unique ID so that the ControlManager can access the right device whenever it is necessary. When a HISSTOWebInterface is called, an User object is instantiated asking for the user ID and the password. The IP address of the machine is automatically detected. Then, the SecurityManager checks the AccessList to authorize the Users access request. Depending on the Users access privilege, corresponding control services are made accessible by the SystemManager object (Figure 3.22).

SytemManager 1..n User name : String password : String ip_address : String accessLevel : Interger 1..n logOn() operateSystem() logOut() 1 1 SecurityManagerInterface <<virtual>> authenticate() <<virtual>> authorize() <<virtual>> editAccessList() 1 1

SecurityManager Occupant FacilityManager etA ccessPrevil iege () heckGl obal Da ta() checkAccessList() authenti cate() 1 authorize() edit Acce ssList()

AccessList add() delete() update()

Figure 3.22: Access privilege management in HISSTO: UML notation

55

3.4.7

Software control implementation

External control among the subsystems of HISSTO is based on the combination of an event driven and a concurrent system. An event driven system has the advantage over the procedure-driven system in term of its simplicity, modularity, flexibility, and better error handling capability (Rambaugh 1991). In an event driven system, the software control is always back to a dispatcher which regulates all external control flows. In HISSTTO, the SystemManager component acts like dispatcher controlling all other subsystems. It activates or delegates specific sensing or actuation, initialization of simulations or a machine learner training, a predictor update process after detecting a change event, the response to a direct user control request etc. To realize such an event driven system, each procedures state needs to be preserved. An event driven system is the proper choice because the entire system can be organized as the collection of separate modules and components and their dependencies are not pre-defined but based on ad-hoc events.

On the other hand, the need for concurrent system control comes from the fact that most subsystems in HISSTO should be able to run in parallel. For example, the system must collect sky condition data from the sensors while allowing the user to raise the dimming level of the luminaires at the same time. This suggests that the system needs to be multi-threaded. Threads allow the system to do multiple processes. Each time an event occurs making a certain action to be performed, the EventManager spawns a thread to handle that request. Once the thread is spawned, the system is free to process other requests even before the first one is completed.

Internal control is specific to each subsystem. The design of each subsystem's internal control should in no way affect the design of the other subsystems. For example, handling various events in an organized way is crucial for maintaining each subsystem truly independent. This is because events could easily complicate on-going operations across different subsystems if they are not handled and notified properly. In the EventManager subsystem, all detected events are constantly observed by the EventObservers in terms of the states of the event sources and their implications. The EventObserverInterface, as an abstract class, provides an interface among various Events and EventObserver objects so that any other subsystem can access the caring events through it. This design guarantees automatic update of the critical information for control and maintenance of the building systems while reducing the complexity of distributing the impact of an event across different subsystems. (Figure 3.23).

56

Event EventObserverInterface <<virtual>> update() 1 1 eventSourceState : Double attach() dettach() notify() handleEvent()

EventObserver observerState : Double update() 1..n 1..n 1

AlertE vent alertEventCode : String getEventSourceState() setEventSourceState()

FailureEvent failureEventCode : String getEventSourceState() setEventSourceState()

ChangeEvent changeEventCode : String 1 getEventSourceState() setEventSourceState()

Figure 3.23: HISSTOs event notification process based on the Observer design pattern: UML notation

The ControlManager subsystems internal control deals with various processes. This subsystem invokes a Control object in a combination of polling and event handling for process control. This component is decomposed essentially into three layers. One thread which polls sensor data through an instance of the MonitoringManager, one thread that actuates the ballasts or the louver motor, and one thread that deals with the system state change based on the outcome predictions and tests of various control options or the request a user has made. The control mode transitions based on the users selection rely on the Strategy design pattern (Gamma et al. 1995). The ControlStrategy object delegates control actions based on the three different control strategies. When an user selects a manual control mode, the ManualControl is activated. During office hours, the PredictiveControl takes initiative which is handed over to the ScheduledControl during off-work hours. These different strategies of a control thread are mutually exclusive. For example, one control mode can be activated anytime but there will never be the case where more than one control mode is activated for a specific control thread. A typical PredictiveControl process involves the outcome predictions and evaluations of the candidate control options followed by the execution of the decided systems state changes. When it is the ScheduledControl mode, the control actions is guided by a pre-determined system operation schedule. The ManualControl needs not to invoke any control outcome prediction or evaluation process. Thus, the desired control action is directly passed to the DeviceControlCommand object. When a certain change occurs, the related building description Views and the Predictors should be updated via updated simulation outputs and the machine learner

57

retraining process. The Strategy design pattern for each control strategy helps to encapsulate the control-mode-specific implementation detail (Figure 3.24). .

Control control_ID : Integer ControlStrategy selectControlMode() performControl() 1 createControlLog() 1 <<virtual>> issueCommand()

ManualControl getUserInput() issueCommand()

PredictiveControl performPrediction() testControlOption() issueCommand()

ScheduledControl identifySchedule() IssueCommand()

Figure 3.24: HISSTOs alternative control strategies based on the Strategy design pattern: UML notation

Figure 3.25 shows the possible transitions among three different building systems control modes. The default control mode is always the PredictiveControl mode considering the fact that it can be the most sophisticated, yet effective way to guarantee user satisfaction and energy conservation in building operation when a proper algorithm is deployed. A manual control request can interrupt any other control mode and remains so, as long as the user maintains the control initiative. During off-work hours including weekend time, the control could be done by a pre-defined schedule which dictates minimum control actions necessary until it is overridden by any user for his/her extended work in the space. Another case in which the transition to the ScheduledControl mode needs to be made is when the Predictor requires update due to a building configuration change or other event which makes the current Predictors knowledge invalid.

58

Start Sy stem entr y / Tur n O n Sy ste m do/ Dis pla y Control Edi tor exit/ Enga ge C ont ro l Building Operation Automatic Control Iterate Cy cle[ iterationPeriod =600 sec ]

Predictiv e Control Scheduled Control [ Predictor needs update ] I dl e do/ Wait Until Next Cy cle Actuation do/ Set State exit/ Update Current S... Idle do/ Check Next Schedule [ Update f inished ] Prediction en tr y / Ch eck Curre nt Stat es do / Perf orm Pr edi ctions ex it / Sel ect Control Opt ion Actuation do/ Set State exit/ Update Current State [ Time ma tche d ]

Select Automatic Control Manual Control

User Ov erides Control

Idle do/ Wait f or User Input

Actuation do/ Set State exit/ Update Current State [ User input detected ]

Figure 3.25: State transition diagram describing HISSTOs control mode changes: UML notation

The other design decision regarding the internal control of the ControlManager subsystem is the way it handles a control command suggested by the Commander object. Various Devices are the potential receivers of the DeviceControlCommand. For a Sensor, it could be the sampling rate change Command. The Execution object creates DeviceContorlCommand object which is stored and invoked by the Invoker object. The Command design pattern allows delayed or conditional execution of the given control commands (Figure 3.26).

59

Invoker 1

Device Actuator 1 deviceID : inte ger actuat eDevic e() re port DeviceStat eChange () 1..n 1 Commander executeControl()

0..n ControlCommand <<virtual>> execute()

Device Con trol Command state : String execute()

Louver: Device

:Commander

:ControlCommand

Invoker

createControlCommand() storeCommand()

actuateDevice()

execute()

Figure 3.26: HISSTOs handling of control command based on the Command design pattern: UML notation

The user interface of HISSTO uses event driven process control. There is one thread for each of the controls on the screen at once so that the user interface can continue to operate even if one of the controls is waiting on a blocking call to another subsystem. There is also a thread of control corresponding to each input modality such as mouse/keyboard. Finally, there will also be a thread to handle the communications with other subsystems.

3.4.8

Boundary conditions
The first step in the start up of HISSTO is to initialize the SystemManager subsystem. Then the ComunicationManager subsystem must be initialized followed by the MonitoringManager and the EventManager subsystems. The UserInterfaceManager is the last subsystem to be initialized. Since this subsystem

60

handles user interface components on the web, the WebServer and the DataSocketServer should be started first before a user can actually access HISSTOs remote user interfaces. Initialization of each subsystem involves starting its internal data structures and any additional resources which it may need. For example, before the ControlManager is performing control decision making, it must obtain sensor readings through the MonitoringManager subsystem. It is possible that a subsystem may attempt to invoke a service which is not yet registered. In this case, the registry will raise an exception to inform the subsystem that the particular service is not yet available. This exception must then be handled on an individual basis by the invoking subsystem.

HISSTOs termination process will be initiated through the user interface. Once started, the system will terminate in the following order: 1) ControlManager 2) MonitoringManager 3) UserInterfaceManager 4) and finally, CommunicationManager. Even though this is a possible termination process, it could rarely happen except when the SystemManager needs to interrupt controlled operation for the maintenance purpose. Most of the time, at least the SystemManager, the ControlManager, the MonitoringManager, and the EventManager are running while other subsystems are activated or deactivated depending on the event captured by the EventManager. The user interface could be separately terminated by closing web browser, which doesnt have impact on the operational status of the remaining subsystems. When any given subsystem terminates, it removes all public services from the registry. This may include, but is not limited to, freeing of memory, de-allocating network resources, and releasing any mutual exclusion locks that certain components of a subsystem may be holding.

HISSTO consists of many subsystems, any of which may fail at any time. No failure can be properly dealt with unless it is detected, but once a failure is detected, the system can take the appropriate measures to correct the problem. A failure in the subsystems other than the UserInterfaceManager will not bring down the entire system. In this case, an error message on the browser notifies that the user interface is not accessible, and the user will not be able to interact with the control system. If the ControlManager does not function properly to yield a control decision, the system automatically switches itself to either manual or scheduled control mode, until the problem is identified and fixed. This could be also the case when all or part of the sensors are not working. If data acquisition is interrupted for long time because of sensor failure, the machine learners retraining might be necessary with the new data set after sensing is restored. To restore service after a subsystem crash, the system should follow its initialization procedure. All failures should be as limited in scope as possible. When failures occur, those parts of the system that can remain functional will do so, and restoration of services will take place as smoothly and rapidly as possible.

61

3.4.9

Adaptation to the system changes

Any information system is expected to be under modifications primarily because multiple sources of change (Bruegge and Tutoit 1999). New vendor or new technology enforces system change by replacing system components; New implementation could be necessary to enhance system performance; New views might be needed for solving usability problems. Therefore, the creation of additional views on the same data is required. HISSTO has a subsystem which describes building configuration. This building configuration has multiple Views and is subject to changes based on the updates or the replacements of building components. In HISSTO, a View is an object describing geometrical and physical properties of the target Zone or the ZoneComponents. This View object can be very complex. By applying the Builder design pattern, construction of a View can be separated from its representation. A client such as the EnvironmentDescriptor instantiates a ViewBuilder as well as a ViewBuilderDirector. The ViewBuilderDirector does a View construction through the ViewBuilder object and the EnvironmentDescriptor gets this View object using getView() method (Figure 3.27) .
1
Enviro nmentDescriptor 1

ViewBuilderInterface <<virtual>> buildView() 1 1

1 ViewBuildDirector co nstructV iew()

Vi ew Vi ewBuilde r

currentView : View* buildView() getView()

1..n

viewType : String viewList : Integer* attachViewElement() dettachViewElement() updateViewElement()

EnvironmentDescriptor

ViewBuildDirector new ViewBuilder

ViewBuilder

new ViewBuildDirector constructView() buildView()

getView()

Figure 3.27: Construction of a View based on the Builder design pattern: UML notation

62

3.4.10 Design priorities

The system design priorities in HISSTO are summarized in Table 3.4.:
Table 3.4: Design priorities of a typical building control system Criteria Correct functionality Efficiency Description The control system should be as bug-free as possible. The system should responds to user input and facilitate efficient solutions to problems. It should be efficient in order to maximize the systems effective life-span. Extensibility The control system should be extensible enough that it will eventually be able to handle even multiple control domains in a building. Fault tolerance Ease of use The system should be resilient to individual server and client failure. The system should be relatively self-explanatory so that the amount of time required to become familiar with it is minimized. Portability The client portion of the system should be usable on multiple platforms, and should be easily ported to a new architecture, should the need arise. Location transparency In order to facilitate portability and ease of use, the actual location of the server on which the "core" of the system is running should be transparent to the clients. Reuse of components The individual subsystem should be easily extractable and applicable to other systems if similar functionality is required.

3.4.11 Design trade-off

Established design goals can sometimes lead to an impasse, a situation where one design goal must be sacrificed in order to achieve another. System-level design trade-offs are identified as follows:

Functionality vs. efficiency: The control process should be handled completely, but it should also be handled quickly. For example, the level of detail in describing building for the simulator influences both the accuracy of prediction and the speed and easiness for preparing the predictor.

Specificity vs. generality: The system should run efficiently according to the user's preferences, but should also be portable to multiple platforms.

Subsystem-level design trade-offs are specific to that subsystem's functionality. For the MonitoringManager and the ControlManager subsystem, performance and accuracy are two potentially conflicting criteria. More frequent sampling rate for the sensors, increased patch numbers in lighting simulation, and larger maximum training steps for a Machinelearner can potentially increase accuracy while sacri-

63

ficing performance. Since both of these two criteria are important, the choice should be made depending on the individual case considering possible tolerance for each criterion.

3.5

Object design
Object design of HISSTO focuses on the detail design of the Predictor, the Tester, and the Commander, structuring the ways in which a building control operation is performed using different hybrid predictors The Predictor design task includes the detail design of the hybridization processes between a simulator and machine learners and the training process of the resulting hybrid predictors. Developing a test algorithm to evaluate the control options generated by the Predictor is the main task of the Tester design.

3.5.1

Object design of the Predictor

The Predictor is a critical part of HISSTO which provides intelligence for control decisions. HISSTOs Predictor has two sub-components: the Simulator and the MachineLearner.

3.5.1.1 Object design of the Simulator In HISSTO, LUMINA is used to predict the values of the daylight performance indicators for candidate control options. To inform LUMINA of the current sky condition, three sensor values (global and diffuse horizontal irradiance and global horizontal illuminance) are included as inputs. Those sky condition variables are obtained from either measurement or the local weather file. Louver angle and luminaire dimming levels in the target space are also among simulation input variables. The outputs of the simulation can be classified into three categories. The first group includes indoor illuminance values on the specified reference points. The second group consists of the reference parameters mostly for glare calculation. Third group represents seven visual performance indicators intended to be used for visual environment control options evaluation. With properly filtered data set and sufficiently calibrated simulation parameters, LUMINA itself can be used as a predictor for daylight responsive lighting control. The advantage of a simulation-based prediction is that the simulator can calculate those performance indicators (i.e. glare and solar gain) that can not be measured in most of actual building settings. Computational and time intensiveness is on its disadvantage list. Figure 3.28 explains the viewer specific simulation input variables for calculating glare indices chosen in HISSTO.

64

altitude viewer(x,y,z) view direction

x-axis

azimuth

y-axis
Figure 3.28: Viewer information necessary for LUMINAs glare calculation

A simulator needs a more sophisticated set of inputs than a machine learner due to the descriptive nature of its modeling process. LUMINA, as a combined daylight and electrical lighting simulation program, needs to have the description of a building and its systems as a part of inputs. Both internal and external surfaces are defined by the x, y, and z coordinates of the vertices along with their physical properties such as transmittance, reflectance, specularity, and diffuseness. Windows are separately defined with a similar set of properties. Site information should be given in terms of its latitude, longitude, height from the sea level, etc. For glare calculation, both the position of the viewer and the view angle need to be specified. Luminaire schedule along with the IES (Illuminance Engineering Society) formatted luminaire information file is also a necessary part of inputs. Reference points on which the illuminance values are to be calculated should be given before running the simulation. Table 3.5 shows the variables selected for the inputs and the outputs of LUMINA as a predictor in HISSTO. Among all listed variables, environmental variables (E0-E5) and the system variable (S1) are the inputs, reference parameters (R1-R17) and performance indicators (P1-P7) are the outputs.

65

Table 3.5: Input and output parameters for LUMINA

ID E0 E1 E2 E3 E4 E5 S1 R1-12 R13 R14 R15 R16 R17 P1 P2 P3 P4 P5 P6 P7 Variable Unit Month Day Hour Description

m d h I hd I hg Ehg LRL En L b1 L b2 Ed Ei L max Em Uf DGI CGI G CRT Q P

Wm Wm lx
degrees

2 2

Horizontal diffuse irradiance Horizontal global irradiance Horizontal global illuminance Light redirection louver angle Indoor illuminance value for the nth reference point Background luminance for DGI calculation Background luminance for GCRT calculation Illuminance on the eye ball due to the direct light component Illuminance on the eye ball due to the indirect light component Value of the maximum luminance patch on the CRT screen Average illuminance across all indoor reference points Uniformity factor in the target space Daylight Glare Index CIE Glare Index due to the electrical light Glare on the computer screen Total solar radiation through the glazing area Total power consumption by the electrical light

lx lm lm lx lx lm lx
-

W W

One of the most important issues in the simulator design is how to maximize its search in the system state space within a given amount of time. The solution for that is to separately deal with electrical lighting calculation and daylight simulation. Since the potential combinations of the possible luminaire dimming states can grow exponentially (assuming there are multiple luminaires in the control zone), developing an efficient way of calculating electrical light is required. In HISSTO, the Luminaire Matrix is devised to avoid otherwise too heavy computation for electrical light simulations.

66

3.5.1.2 Object design of the MachineLearner

The MachineLearner objects for HISSTO are all supervised learners implemented in neural networks using back-propagation as the weight-tuning rule and sigmoid function for treshold function. Since a Simulator can provide prior knowledge for a MachineLearner, supervised learning is the best choice compared to others. Different designs of the neural networks provide exploratory benefits in the hybridization process. At least two major ways of the hybridization are covered: direct knowledge transfer from the Simulator to the neural networks through a copying mechanism and the neural network assisted simulator calibration.

System Identification (SI) is the process in which a neural network identifies system behavior by observing systems inputs and outputs. Estimated system parameters by this method can be used for system behavior prediction or system control purpose. Measurement-based neural networks in HISSTO are classified into this category.

Copying Existing Model (CEM) is another way of designing a neural network which can be trained from the data set generated by an existing model or a human expert. Since simulation can generate all output parameters necessary for HISSTOs prediction capability by having almost the same inputs most of the neural networks require, copying simulation knowledge into a neural network becomes an attractive option, especially for minimizing computational load and time otherwise necessary for simulations.

On top of those two categorization of neural network usages, a couple of other issues are identified in selecting proper neural network designs for HISSTO. Number of indoor illuminance sensors is an issue because it is not feasible to use a large number of sensors in a target space beyond certain period of data collection phase. For this reason, it is necessary to have the neural networks trained and operable with only limited number of indoor illuminance sensors. Neural networks lack of access to a certain group of visual performance indicators (i.e. glare indices and solar gain through glazing) creates a challenge. Since obtaining actual sensor readings for those performance indicators is difficult, a neural network has to rely on the simulator for predicting the values of such indicators. This neural network obtains average illuminance and uniformity factor calculated from the direct measurement or the predicted indoor illuminance values by other neural networks, then predicts the rest of outputs (both reference parameters and remaining performance indicators) based on the training done with weather file-based simulations. To train this neu-

67

ral network, simulation generated training patterns must be used, because only the simulator can generate the values of those unmeasured performance indicators.

Considering those MachineLearner design issues in HISSTO, seven different neural networks are created. Each of the neural networks designed in HISSTO varies mostly by its inputs and outputs as well as the source of the training patterns.

1) MSNN(1) in SI category uses measurement data for training and predicts indoor illuminance distribution across multiple reference points.

2) MSNN(2) in SI category uses only one indoor illuminance sensor for its training. Even though it can only predict a single reference point illuminance without being able to deal with average illuminance and uniformity factor, it provides a fairly scalable solution in the real lighting control setting because placing a large number of sensors in any control zone is not always a practical solution.

3) SMNN, a simulation based neural network in CEM category, uses the training patterns generated by the simulator with the recent sky condition measurement. This neural network is designed to replace the simulator on condition that its predictive capability matches that of the simulator within an acceptable deviation range. Generation of the training patterns for the SMNN needs a dedicated period of time during which the measurement of sky condition parameters (E3-E5) is performed.

4) WFNN(1) in CEM category uses local weather file to generate a sufficient number of training patterns using the simulator. The expected advantage of this neural network is the agile preparation of training patterns as long as the pertinent local weather file is acquired. The accuracy of prediction can be the major issue with this neural network since it does not have any chance of being calibrated based on the real measurement. This neural network predicts all reference parameters and performance indicators necessary for HISSTO.

5) WFNN(2) in CEM category is another type of neural network addressing calibration issue. Similar to WFNN(1), this neural network is trained with the training set generated by the local weather file-based simulations. It predicts only a subset of performance indicators such as average illuminance and uniformity factor which can be calibrated by the indoor illuminance sensors during its operation time.

6) SMCNN in CEM category is the calibration neural network designed to learn the simulators indoor illuminance prediction errors. Once trained, it can calibrate simulation output by predicting the possible deviation of the simulators output from the measurement.

68

7) BRIDGENN (Bridge Neural Network) in CEM category is to relate other neural networks indoor illuminance prediction to the predictor outputs such as reference parameters (R13-17) and the performance indicators (P3, P5, and P6) other than the average illuminance and uniformity. This neural network gets average illuminance and uniformity value (measured or predicted by another neural network) as a part of its inputs, then predicts the rest of other outputs needed in HISSTO. To do this, the neural network is trained with the training patterns that the local weather file-based simulation generates.

Table 3.6 and Table 3.7 show the input and output parameters for each of those neural networks designed in HISSTO. The neural networks take solar azimuth and solar altitude as a part of input parameters instead of the time stamp. This is for reducing the number of input variables while maintaining the minimum meaningful set of data to train neural networks.
Table 3.6: Input and output parameters for the neural networks designed in HISSTO
ID E1 E2 E3 E4 E5 S1 R1-12 R13 R14 R15 R16 R17 P1 P2 P3 P4 P5 P6 P7 Variable Unit degrees degrees Solar azimuth Solar altitude 2 2 Horizontal diffuse irradiance Horizontal global irradiance Horizontal global illuminance Light redirection louver angle Indoor illuminance value for the nth reference point Background luminance for DGI calculation Background luminance for GCRT calculation Illuminance on the eye ball due to the direct light component Illuminance on the eye ball due to the indirect light component Value of the maximum luminance patch on the CRT screen Average illuminance across all indoor reference points Uniformity factor in target indoor space Daylight Glare Index CIE Glare Index due to the electrical light Glare on the computer screen Total solar radiation through the glazing area Total power consumption by the electrical light Description

I hd I hg Ehg LRL En L b1 L b2 Ed Ei L max Em Uf DGI CGI G CRT Q P

Wm Wm lx
degrees

lx lm lm lx lx lm lx
-

W W

69

In principle, all input and output parameters of a neural network are supposed to be measured. But, a subset of neural networks designed in HISSTO have the outputs predictable only through being trained with the data set generated by the simulator. Therefore, the validity of those neural networks can only be judged relative to the simulators predictions instead of being directly compared with the measurement.

Table 3.7: Selected input(I) and output(O) parameters for each neural network designed for HISSTO
MSNN(1) E1 E2 E3 E4 E5 S1 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16 R17 P1 P2 P3 P4 P5 P6 P7 I I I I I I O O O O O O O O O O O O SMNN I I I I I I O O O O O O O O O O O O O O O O O O O O O O WFNN(1) I I I I I I O O O O O O O O O O O O O O O O O O O O O O SMCNN I I I I I I O O O O O O O O O O O O MSNN(2) I I I I I I O WFNN(2) I I I I I I O O O O O O O O O O O O BRIDGENN I I I I I I O O O O O I I O O O -

To represent each of the different neural network designs, a special naming convention is established. The First two capital letters indicate the source of the neural networks training patterns. (MS: MeaSurement, SM: SiMulation, WF: Weather File). The character C after that denotes the calibration routine with the number of illuminance sensors used for the calibration. The last two letters NN indicates that the final form of the hybrid predictor is a neural network. Separate from the naming convention, Figure

70

3.29 shows the iconic representation of the neural networks designed for HISSTO.

Source of Knowledge M: Measurement S: Simulator W: Weather file Neural Network Type 1. SI 2. CEM

M/S/W

Number of Sensors for training Single/Multiple

?1
2 2

1. BRIDGENN 2. Necessity of BRIDGENN

Sensors in operation

P S

Simulation

Absence of an element

Prediction

Figure 3.29: Iconic representation scheme of the neural networks designed for HISSTO

Table 3.8 shows the design characteristics of HISSTOs seven component neural networks serving as the major building blocks of the hybrid predictors. Some neural networks in HISSTO - i.e. MSNN(2), SMNN, and WFNN(1) - can perform necessary predictions without being combined with any other system component or neural network. Others need BRIDGENN to be functional as the predictor due to the incompetence of reaching those output variables only accessible by the simulator (i.e. MSNN(1)), or to re-calculate all outputs after being calibrated by other system component such as the calibration illuminance sensor value (i.e. WFNN(2)), or the other neural network predicting the simulation error (i.e. SMCNN). Designing multiple component neural networks and the different ways of hybridization to come up with various hybrid predictors are considered to be appropriate especially when each hybridization strategy has potential benefits and disadvantages depending on the context and available resources. In HISSTO, the combinations of the component neural networks, the simulator, and the illuminance sensors provide intended variations in the hybrid predictors design and implementation.

71

Table 3.8: Design characteristics of the neural networks to construct HISSTOs predictors ID MSNN(1) Icon
Description

Inputs E1-5, S1

Outputs R1-12

Type SI

M ?
MSNN(2)

-NN trained with measurement data having multiple indoor illuminance values -This NN needs the BRIDGENN to predict unmeasured performance indicators. -NN trained with measurement data having a single indoor illuminance value -This NN Predicts only a point illuminance value and doesnt need the BRIDGENN. -NN trained with the measured sky condition-based simulations -This NN predicts all performance indicators including the unmeasured ones. -NN trained with the data generated by the local weather file-based simulations -This NN predicts all performance indicators including the unmeasured ones. -NN trained with the data generated by the local weather file-based simulations -This NN only predicts only indoor illuminance profile and needs the BRIDGENN to complete the prediction. -NN trained with the data generated by the local weather file-based simulations having average indoor illuminance and uniformity as a part of its inputs. -This NN predicts the unmeasured performance indicators. -NN trained with the simulator error patterns -This NN needs simulations before calibration and the BRIDGENN to complete the prediction. -This NN needs indoor illuminance measurement to maintain its calibration capacity.

E1-5, S1

M ?
SMNN

R1 or,... R12

SI

E1-5, S1

s
WFNN(1)

R1-17, P1-P3, P5-P6 R1-17, P1-P3, P5-P6 R1-12

CEM

E1-5, S1

CEM

WFNN(2)

E1-5, S1

CEM

BRIDGENN

W
B

E1-5, S1, P1-2

R13-17, P3, P5 P6

CEM

SMCNN
SM

E1-5, S1

R1-12

CEM

Figure 3.30 shows the generic structure of the neural network design in HISSTO which has only one hidden layer in addition to input and output layer. Depending on the type of neural network designed in HISSTO, each neural network keeps only a subset of input and output nodes illustrated in the diagram. For example, BRIDGENN takes average illuminance (Em) and uniformity (Uf )as the additional inputs instead of having them as outputs, which requires two more nodes in the hidden layer.

72

E1 E2 E3 E4 E5 E6 E7

E8 E9 E10 E11 E12 Lb1 Lb2 Ed Ei Lmax Em Uf DGI GCRT Q

Figure 3.30: Generic architecture of the neural networks in HISSTO

Ihd Ihg Ehg LRL Em Uf

73

Neural network training parameter set-up

Each neural network can have an unique set of training parameters to get the best result. Normally, learning rate and momentum are the most sensitive training parameters to be optimized. With multiple trials, it has been identified that learning rate 0.0001 and momentum 0.95 work for the most of neural networks designed for HISSTO. The termination point of a neural network training process can be determined by specifying either the maximum allowable prediction error or the maximum number of training steps the neural network adjusts the weights of its links. Maximum number of training steps also has implication for the speed of the training: around 2,000 steps yields fairly stable result across most of the neural networks tested.

Neural network training

Training of a neural network in HISSTO is done with the training patterns either from the simulations or the measurement. Partitioning of the data set for training and testing is important especially for the proper validation of the neural networks prediction capability. In HISSTO, basically three different data partitioning approaches have been tested (Figure 3.31). Generally speaking, the train and test data set of a neural network need to be adequately apart in time dimension to check how far the trained neural networks prediction capability can be generalized. One way of doing this is the shuffle-and-select method in which a train or a test data set is randomly chosen among multiple segments of a data pool which are shuffled every time a new selection is to be made. This is a good way of testing neural networks prediction performance when the training patterns are homogeneously distributed throughout the entire data pool. Nevertheless, this data set partitioning scheme is less meaningful in HISSTOs actual system control operation context not to mention the embedded technical complexity of implementing this method.

The second approach is the cumulative data set partitioning method. The entire cumulated data set up to the current control time interval is used for training a neural network to predict control outputs for the next control time interval. As time passes, the data set for training is growing in its size, which is a critical shortcoming of this approach. Without giving certain incentive for the most recent part of the data set, the trained neural networks up-to-date prediction capability possibly fades by being enforced to fit weights across the entire training patterns distributed throughout the cumulated data sets. Even though it is not a scalable solution considering the magnitude of data the control system eventually gets during its continuous operation, this scheme can be useful when the data collection is necessary only for a certain period of time.

74

The third approach is sliding time window method. In this method, training is done with only the most recent data set to predict the control outcome of the next control time interval. This "sliding time window" approach is scalable because it always uses a constant volume of data to train neural networks on a regular basis. Since daylight responsive lighting control requires at least quasi-real-time states of the environmental variables (i.e. sky condition), this scheme can keep the neural networks continuously being updated. One of the important issues with this training scheme is to determine the size of the time window to maximize the neural networks learning capability while minimizing the computational load without losing a grip on the environmental changes. Experiments show that a 4-5 days of time window guarantees a reasonable performance of the neural networks designed for HISSTO.

Shuffle and select Training Prediction Cumulative

Sliding time window

Figure 3.31: Different neural network training schemes based on the progression of time

Neural network training pattern encoding & output decoding

A neural network requires all the values in a training pattern between 0 and 1, preferably between 0.2 and 0.8 for the best training result. This is because the sigmoid function that a neural network uses to modify node input value for better fitting non-linearity performs well within this value range. For this reason, all the inputs of the neural network should first be encoded and its outputs must be decoded. This requirement is a challenge for the implementation of neural networks designed in HISSTO. The challenge comes from two different sources. First, the input and output values for these neural networks have all different boundary of variations some of which are too widely dispersed to make them fit the

75

required value range. Secondly, certain variables are changing too dynamically (i.e. environment variables and reference parameters which depend on the sky condition at a particular moment). Both scale and offset are normally used for encoding training patterns and decoding prediction outputs. Especially for scaling, either arithmetic or logarithmic scale can be applied depending on the characteristics of a specific variable. Logarithmic scale can compress a large number into a small one, making the neural network comparatively sensitive to the value changes in the lower magnitude with any widely ranged variable. Sky condition variables such as outdoor illuminance values are suitable for this type of manipulation. On the other hand, tightly bounded variables such as uniformity and glare indices can be processed with arithmetic scale. Preliminary test shows that even combination of these two different scaling methods would work properly. To ensure every encoded variable in a training pattern is within the desired value range, a special numeric transformation process has been devised. Suppose T is a training pattern, and P is a prediction output of a neural network, any element variable of T or P can be encoded/decoded by applying both scale ( a ) and offset ( b ) based on the following process:

a max ( t i ) + b = for .2 0.8 and t i T a min ( t i ) + b = for 0.2 < < , which yields, a = ( ) ( max ( t i ) min ( t i ) ) and b = ( 2 ) a ( 2max ( t i ) min ( t i ) )

Where ti is the encoded value for the ith variable in T,

ti = a t i + b

(3.3)

Where pi is the decoded value of pi , the ith variable in the output P,

pi b p i = -------------a

(3.4)

The same transformation could be done with logarithmic scale.

t ( sm ) i a log max ( ti ) + b = for 0.2 0.8 and t i T , or t i = -------------- especially for the simulation calit ( ms ) i

bration network (SMCNN), where t ( sm ) i is the simulated value and t ( ms ) i is the corresponding measurement of the ith variable in T,
a log min ( t i ) + b = for 0.2 < < , which yields, max ( t i ) a = ( ) log ------------------ min ( t i )

76

b = 2 a ( 2 log max ( t i ) log min ( t i ) )

Where ti is the encoded value for the ith variable in T,

ti = a log ( ti ) + b

(3.5)

Where pi is the decoded value of pi , the ith variable in the output P,

pi b -------------- a

p i = 10

(3.6)

When the neural network is SMCNN, decoded output element Pi is

p ( sm ) i p ( ms ) i = --------------------pb 10
i -------------- a

(3.7)

By using this encoding/decoding scheme, every variable in a training pattern T can be converted into the number between 0.2 and 0.8 and the neural network output is decoded back properly after the prediction is made. One of the problems for applying this method comes when the range of a value in all training patterns can not properly accommodate the current or future variations of its value the neural network uses in operation. One way to solve this problem is to use squeezed and values so that the encoded inputs for prediction could be kept within the desired ranges. Sometimes, simply setting a fixed boundary for each variable in a training pattern based on its probable range of variations can be effective in preventing this type of problem.

3.5.1.3

Object design of the hybrid predictors Six different hybrid predictors have been designed and implemented for HISSTO. They vary mainly by their inputs and outputs as well as the source of knowledge for training - either simulation or measurement (Chang and Mahdavi 2001).

The predictors role in HISSTO is to provide means for directed exploration throughout the building systems control state space. Unlike undirected exploration where actions are generated randomly with uniform probability distribution, the directed exploration utilizes certain exploration-specific knowledge for guiding its process (cp. Thrun 1991). The internal process and the characteristics of a hybrid predictor varies depending on the component neural networks the hybrid predictor uses. There are three groups of hybrid predictors designed in HISSTO. Three hybrid predictors use measurement based neu-

77

ral networks. The other two hybrid predictors are based on the model copy neural networks. The remaining one hybrid predictors uses a neural network built for the simulator calibration.

The six hybrid predictors designed in HISSTO are: 1) Predictor using multi-sensor measurement-based neural network: (MSC0NN): This hybrid predictor is using MSNN(1) trained with measurement data only. Since MSNN(1) solely relies on the measurement, it has problems in predicting those reference parameters necessary for calculating glare indices as well as the other performance indicators which cannot be measured. Therefore, once the MSNN(1) predicts the indoor illuminance distribution, both average illuminance and uniformity are calculated and fed to the BRIDGENN as a part of its input. The BRIDGENN then predicts all other reference parameters as well as the other performance indicators. Another issue for this predictor is the number of indoor illuminance sensors. Having ever-present multiple sensors within a control zone is not realistic. For this reason, using multiple sensors for the component neural network training can only be allowed during a limited period of time. The decay pattern of its prediction capability as time passes then becomes interesting issue for observation.

2) Predictor using single sensor measurement-based neural network: (MS1NN) This hybrid predictor uses MSNN(2) neural network trained with only one indoor illuminance sensor value. With just one indoor illuminance reference point, some of the performance indicators selected for evaluating control options can be meaningless. For example, uniformity factor can not be calculated with a single illuminance value. Selecting an adequate reference point is, therefore, crucial for this predictor. Unlike MSC0NNs case, feeding only one sensor value to this predictor for training is a sustainable operation scenario in reality even though its coverage of control performance criteria is significantly limited.

3) Predictor using simulation copy neural network: (SMC0NN) This hybrid predictor uses SMNN trained solely with the training patterns derived from the simulation inputs and outputs. Since the simulations for training pattern generation is based on the measured sky conditions of the past, this hybrid predictors performance depends heavily on the similarity of the weather conditions prior to the time performing actual prediction. How closely the component neural network can copy the simulator is another issue. This predictor doesnt need the BRIDGENN because the source of knowledge for this predictor is the simulator and each training pattern includes all output variables to be predicted.

4) Predictor using weather file based simulation copy neural network: (WFC0NN) This hybrid predictor uses WFNN(1) trained with the patterns generated by the simulator based on the

78

local weather file instead of relying on the simulations with the measured sky conditions during the past 4-5 days of time period. In the beginning of each month, the simulator takes current months weather file data and generates hourly-based predictions over the reference parameters and the defined performance indicators for each louver control option for the entire month. The neural network component of this predictor doesnt need any measurement data as long as the local weather file is available. Since the component neural network also relies on the simulator for training, its prediction capability should be almost as good as or even better than the one trained by the simulator with measured past sky conditions (SMC0NN).

5) Predictor using neural network calibrated simulation: (SMC12NN) The simulation result can be calibrated on-line to capture the system behavior more precisely. This hybrid predictor uses SMCNN, a neural network to calibrate simulation output by learning the simulators prediction error. This approach assumes that the simulation prediction error has a certain pattern so that a machine learner can capture and compensate for it as long as the building configuration and systems configurations are remain unchanged. Whenever a change occurs, SMCNN should be retrained on-line. To operate this hybrid predictor, daylight simulation must be done first. Then the simulation output (i.e. indoor illuminance profile) is calibrated by SMCNN, average indoor illuminance and uniformity are calculated and the BRIDGENN completes the rest of the prediction task. Since SMCNN uses multiple indoor illuminance sensor values for training, this predictors decay pattern over time is important to consider. Whenever a change occurs, SMCNN, the component neural network for simulation calibration, should be retrained for a successful adaptation to the changed condition. Figure 3.32
and Figure 3.33 describe SM12CNNs training and prediction process.

1: getZoneDescription() LightingZone: View LightingSimulator: Simulator

2: getSkyCondition() LightSensor: Sensor

3: getSimulatorOutput PredictionErrorIdentifier: rainingPatt ernBuilder

: NNTrainingPattern

4: getMeasurement

5: generateTrainingPattern

6: getTrainingPattern 7: performTraining NeuralNetworkTrainer: MachineLearnerTrainer SMC12NN: MachineLearner

Figure 3.32: Collaboration diagram describing SM12CNNs training process: UML notation

79

LightingZoneView: View 1: getZoneDescription() 2: getSkyCondition LightingSimulator: i mulat or 3: generateOutput() 6: getSkyCondition() imulat orPredic tion: Prediction LightSensor: Sensor

Database

4: getTrainedNNWeights()

NeuralNetworkBuilder: MachineLearnerBuilder

5: createNeuralNetwork()

SMC12NN: Machi neLearner 7: generateOutput() 9: getDeviat ion()

8: getPrediction() PredictionCalibrator: Calibrator 10: calibratePrediction() FinalPrediction: Prediction

SimulatorErrorPrediction: Prediction

Figure 3.33: Collaboration diagram describing SM12CNNs prediction process: UML notation

6) Predictor using calibrated weather file based simulation copy neural network: (WFC1NN) This hybrid predictor uses WFNN(2), a neural network trained with weather file-based hourly simulations to predict the indoor illuminance profile. It then calibrates the prediction result using only one real-time indoor illuminance sensor value. In this calibration process, the difference between the measured illuminance value and the predicted one is applied uniformly to the other reference points. After the calibration, it uses BRIDGENN to generate the final prediction output (Figure 3.36). Identifying a proper reference point is, therefore, crucial for this hybridization scheme. Similar to MS1NNs case, feeding only one indoor illuminance sensor value to this network for real-time calibration makes this predictor practical in actual building operation.

Figure 3.34 shows an exemplary collaborative process between WFNN(2) and BRIDGENN to perform necessary prediction with WFC1NN hybrid predictor in HISSTO.

80

R1 (E1) R2 (E2) ................ Calibrate

Default Inputs

Predict WFNN(2)

Sensor

R12(E12)

R13 - R17 DGI GCRT Q Em Uf BRIDGENN Predict

Default Inputs Em Uf

Figure 3.34: Exemplary collaborative process between WFNN(2) and BRIDGENN in WFC1NN

Table 3.9 and Figure 3.35 illustrate how each designed hybrid predictor is trained and performs prediction in relation to the other system elements.

81

Table 3.9: Diagrammatic description of each hybrid predictors prediction process

Predictor
MSC0NN M ?

Prediction process

Description
1. Predict indoor illuminance profile using MSNN(1) 2. Predict remaining performance indicators using BRIDGENN 1. Predict a single illuminance value on the chosen reference point using MSNN(2)

W B P

MS1NN M ? SMC0NN S P P

1. Predict all performance indicators using SMNN

WFC0NN W P

1. Predict all performance indicators using WFNN(1)

SMC12NN S
SM

W B

1. Predict indoor illuminance profile using the Simulator 2. Calibrate simulation output with SMCNN 3. Predict remaining performance indicators using BRIDGENN 1. Predict indoor illuminance profile using WFNN(2) 2. Calibrate the output with one illuminance sensor value 3. Predict remaining preference indicators using BRIDGENN

WFC1NN W W B P

82

indoor illuminance solar azimuth solar altitude sky condition louver

d1 d6

input c1 training calibration output

training pattern
t1

deviation neural network

d4 s2 d2 d3 s1 s3 n2 n1 b1

prediction output

simulator
d5

bridge neural network

time building geometry local weather file

MSC0NN: d1 t1 WFC0NN: d2 WFC1NN: d2 s1 s1 d4 n2 d5 b1 MS 1 NN: d1 t1 d4 n1 n2 SMC12NN: d3 s2-d1 d6 c1 d5 b1 n1 SMC0NN: d3 s1 s3 d4 n2 t1 d5 d4 b1 n1 t1 d4 t1 d4 t1 d3

Figure 3.35: Training and operation processes of the different hybrid predictors in HISSTO

3.5.2

Object design of the Tester

Once the daylight prediction is completed by any predictor in HISSTO, an additional evaluation process to select desirable louver angle needs to be performed. Because the hybrid predictors are only for the daylight prediction task, the electrical lighting calculation is done separately by using a pre-calculated Luminaire Matrix. After this, selection of the most desirable luminaire dimming level combination with the chosen louver angle should be performed. The Tester in HISSTO realizes this process with an evaluation algorithm which filters all candidate target systems states through a predefined set of visual environment assessment criteria.

3.5.2.1 Visual performance evaluation criteria

An attractive feature of a model-based control strategy is the diversity of the performance indicators that can be incorporated into the control option evaluation process. Furthermore, these performance indica-

83

tors need not to be strictly limited to strictly visual criteria (i.e. illuminance level), but also can include cross-domain performance criteria (i.e. heat gain and energy use). In HISSTO, the simulator predicts the values of the seven performance indicators: average illuminance calculated from the illuminance values on the multiple reference points in a space, uniformity of illuminance distribution on the specified plane in a space, glare due to daylight (DGI, cp. Hopkinson 1971), glare due to electrical light (CGI, cp Einhorn 1979), glare on the computer screen (GCRT), solar gain (Q), and electrical lighting power consumption (P).

Average illuminance: Mean of the indoor illuminance values for all reference points to represent the light level in a target space. This can be formularized in the following expression:
n

1 E m = -- n

Ei
i=1

(3.2)

where n is the number of all reference points.

Uniformity: The uniformity factor indicates the evenness of the illuminance distribution within a space. This can be expressed in the following formula which yields the uniformity value between 0 and 1 (UE, cp. Mahdavi and Pal 1999):
Em U E = ---------------------E m + ESD

(3.3)

where ESD is the standard deviation and Em is the average value of all illuminance values.

DGI: Daylight glare can be a critical source of visual discomfort since it is usually in the direct field of view having high luminance. Glare index assessing discomfort glare due to the daylight specifically addresses this condition. Among many daylight glare models, the most widely accepted one is the Daylight Glare Index (DGI, Hopkinson 1971). This can be expressed in the following formula.

Ls DGI = 10 log 0.478 ---------------------------------------------0.5 L b + 0.07 L s

0.8

(3.4)

Where

Ls Lb

solid angle subtended by the glare source (window) modified by the position factor luminance of the glare source in the field of view luminance of the background total solid angle subtended by the window at the eye

84

CGI: The glare caused by an electrical lighting source. This CIE Glare Index was developed by H. D. Einhorn 1979 and accepted by the CIE Committee of Discomfort Glare as the standard glare index to be used for discomfort glare due to the electric lighting. The formal expression of this glare is:
Ed 2 1 + -------500 ------------------ L s - --------CGI = 8 log 2 2 Ed + Ei p

(3.5)

where

Ed Ei Ls

direct illuminance on the vertical surface of the eye indirect illuminance on the vertical surface of the eye luminance of the glare source in the field of view total solid angle subtended by the window at the eye
2

Here, the solid angle is modified by p

which is a position factor to take into account the occupants

line of sight relative to the glare source. It is given by:

d e x = ----------------------------------- + 0.12 ( 1 e ) 2 d + 1.5d + 4.6 0.18 d

2

2 x

where x = --------- s + ------------ s D S d = --- , s = --H H D S H

0.011 d

horizontal distance to the glare source parallel to the line of sight horizontal distance to the glare source perpendicular to the line of sight height of the glare source above the eye position

GCRT: Glare on the computer screen depends on the locations and the relative angle of the viewer and the computer monitor. Both daylight and electrical lighting source should be considered. This glare can be expressed in the following formula:

1 G CRT = ------------------- L max

i=1

------------------------------------2 r
i

L i cos i cos i

(3.6)

where n is the number of interior surface patches, L i is the luminance of the ith surface patch, Ai is the area of the ith surface patch, i is the angle between the normal of the ith surface patch and the line connecting the centers of the ith surface patch and eye patch, i is the angle between the normal of eye patch and the line connecting the centers of surface patch and eye patch, r i is the distance between the

85

ith surface patch and eye patch, L max is the maximum luminance value identified among CRT screen patches.

Solar gain: The amount of solar radiation introduced to a space through the glazing area. This can be roughly estimated based on the following formula:
n

1 Q sol = --

Ei Ai i
i=1

(3.7)

where n is the number of window patches, E i is the illuminance on the ith window patch, A i is the area of the ith window patch, i is the solar transmittance of the ith window patch, and is average luminous efficacy.

Power consumption: The amount of energy consumed by the luminaires in a target space. Operation of daylight systems (i.e, louver or blind) has also energy implication since it can increase/decrease heating/ cooling load. This concern is left out in calculating power consumption because it requires a complex tracking of all related HVAC components and is already taken into account by the solar gain performance indicator. The power consumption by electrical lighting can be represented with the following formula:
n

P=

Pi
i=1

(3.8)

where n is the number of luminaires in the target space and P i is the power consumption of the ith luminaire.

User's preference for the desired values of those selected visual performance indicators may be expressed by graphic means. Illustrative examples of preference functions for the performance indicators are given in Figure 3.36 (a: Average illuminance, b: Uniformity, c: DGI, d: CGI, e: GCRT, f: solar gain in winter g: solar gain in summer, h: power consumption).

86

1.0

0.8

c,

Preference index

0.6

d a a b b

0.4 0.2 0

a
0

lx
500 1000 1500 2000 2500 3000 3500 4000 4500 5000

b
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0

1.0

c, d, e

Preference index

0.8

g, h
0.6

0.4 0.2 0

f, g, h c, d, e

c.
0 3 6 9 12 15 18 21 24 27 30

d.
0 2 4 6 8 10 12 14 16 18 20

0.3

0.6

0.9 1.2 1.5

1.8

2.1 2.4 2.7

3.0

Figure 3.36: Exemplary preference functions for HISSTOs performance indicators

Those preference functions provide the basis for the derivation of objective function toward the evaluation of control options (Mahdavi 1993). An objective function may be based on a single performance indicator, or on a weight aggregate of two or more performance indicators. An example of such a utility function U is given in the equation 3.9 below.

87

Maximize U, where U=WE x PE + WUE x PUE + WDGI x PDGI +WCGI x PCGI + WGCRT x PGCRT + WQ x PQ+ WP x PP
0 W, P 1 and

(3.9)

= 1,

WE: Weight for average illuminance WUE: Weight for uniformity factor WDGI: Weight for Daylight Glare Index WCGI: Weight for CIE Glare Index WGCRT: Weight for Glare on CRT WQ: Weight for solar gain WP: Weight for luminaire power consumption PE: Performance indicator for average illuminance PUE: Performance indicator for uniformity factor PDGI: Performance indicator for Daylight Glare Index PCGI: Performance indicator for CIE Glare Index PGCRT: Performance indicator for Glare on CRT PQ: Performance indicator for solar gain PP: Performance indicator for luminaire power consumption

Needless to say, such weightings involve subjective and contextual considerations and may not be standardized. Rather, preference functions and the weighting mechanism are intended to provide the user of the system with an explorative environment for the study of the relative implications of the impact of various performance indicators in view of preferable control strategies (Mahdivi et al. 1999).

3.5.3

Object design of the Commander

After the best control option is identified, the Commander object checks other on-going control actions to avoid any potential global conflict before the execution of the control decision. This is done by predefined heuristic rules implemented as if-then clauses. Another part of the Commander objects services is to ensure a seamless execution of the control commands through the software/hardware interfaces connecting the actuators to HISSTO. For HISSTO, both light redirection louver and luminaire actuation interfaces use digital signals generated by the DeviceControlCommand. The louver control is done through a serial connection to the louver motor control circuit board. The luminaire control is

88

implemented through an A/D converter embedded on a PC control board passing a converted analog signal to each luminaire ballast for dimming. Based on the Command design pattern, a ControlCommand can be further elaborated for better control quality. For example, when there is significant difference between the current luminaire dimming level and the newly suggested one, the ControlCommand will be executed by gradually increasing (or decreasing) the luminaire power level up (or down) to the desired state instead of changing it at once. This type of elaborated control command execution process is specified in one of the member functions of the DeviceControlCommand object.

3.5.4

Object design of the Sensor

The sensors connected to HISSTO capture necessary physical properties of the environmental or the system objects based on the proper sampling rates. This is important especially for the predictors to provide the required services. Both illuminance and irradiance sensors are the key elements in visual environment control in addition to the systems state sensors such as the luminaire power level sensor and the louver angle sensor. Considering possible future extension, the sensors used in HISSTO should have generic representation to maintain vendor-independency and interoperability. Table 3.10 shows the list of primary sensor types and their characteristics used in HISSTO. For detail information, see Appendix sections A.1.1 and A.1.2.
Table 3.10: Various sensors used in HISSTO Type Photometric sensor Pyranometer Luminaire power level sensor Louver position sensor Description measures illuminance measures irradiance reports luminaire power level reports louver angle Sampling rate 1/min 1/min 1/state change 1/state change

On the server side, the system maintains connection to all sensors for monitoring purpose. The data acquisition period can be customized and the data collection cycle can be activated every 10 minutes between 9 AM and 6 PM.

The data acquisition module performs sampling, processing, and logging of the sensor values. The facility manager can specify scan rate, buffer size, and reading rate for an optimized data acquisition. After all active sensor channels are properly scanned and read, the captured data may need to be further processed to yield desirable data format. For example, if one sensor channel is scanned during several minutes, the calculated average of all scanned data instances can represent the sensor value for that specific time interval. This is absolutely necessary to avoid the situation where an instantaneously retrieved sen-

89

sor value does not represent the overall trend due to the fluctuation of its value over time. Once the collected data set is properly processed, it can be either displayed or archived with an attached time stamp. A.1.4.2 section in the Appendix A describes the data acquisition module interface.

Training of a neural network requires a systematic data acquisition plan. For this purpose, the facility manager can specify the louver status (either on or off), the increment of the louver angle changes within a data acquisition cycle as well as the duration of the data collection after the louver is positioned at a certain angle before it moves to the next position. Luminaires can also be either turned on or off during a data acquisition cycle. In HISSTO, the data acquisition interval is typically set to 10 minutes.

HISSTOs monitoring component has the server side interface for displaying the captured sensor values on the screen in both numeric or graphic format. This is basically for the facility manager rather than ordinary users. Multiple indoor illuminance sensor values along with global horizontal illuminance, global horizontal irradiance, and diffuse horizontal irradiance value are among the ones to be displayed. Different color can be used to identify each sensor in the graph. Numeric display is added for each sensor to provide more precise reference.

3.5.5

Object design of the Actuator

The Actuator represents a mechanical/electrical device responsible for controlling a system. Depending on what type of systems the target control zone has, corresponding actuators should be identified and modeled properly. The actuation in HISSTO is finalizing either manual, scheduled or predictive control of the louver and the luminaires. An Actuator object in HISSTO can provide interfaces to dimmable luminaire ballasts, blind controller, light redirection louver controller, or the other internal or external daylight modification devices. Once a control action is completed, numeric or graphic indicators confirm the outcome of this control action. Modeling of an Actuator should allow vendor-independent and inter-operable interfacing so that it can accommodate a variety of manufacturers and products without significant code change.

3.5.6

Object design of the daylight responsive lighting control

Instead of evaluating all possible instances of combined daylight and electrical lighting control options, HISSTO assesses each of those separately and combines the results later to avoid an explosion of the control state search space. Certain performance indicators address only daylight (i.e. heat gain), some are derived only from electrical light (i.e. power consumption), and others need to consider both. For example, computations of glare indices require the knowledge of background luminance, which is

90

affected by both daylight and electrical light. A pre-calculated Luminaire Matrix for electrical lighting assessment is proven to be effective. Figure 3.37 shows how the daylight prediction and evaluation for the louver angle selection can be integrated with the outcome of electrical light calculation based on the Luminaire Matrix look-up process. The variables used in the diagram are depicted in Table 3.5. The following steps show a typical daylight responsive lighting control process designed for HISSTO:

1) Outdoor daylight sensor values, current louver position, current luminaire power levels, and current time are identified.

2) Either a simulation or a hybrid predictor-based prediction is done for each of the eight louver positions based on the input data. Calculated performance indices for each louver position are further processed to generate the utility value U based on the defined preference indices and corresponding weights, then the louver position that maximizes the utility (see equation 3.9) is selected (i.e. 105 degrees).

3) Another round of simulation for the chosen louver position is performed to generate glare components enabling glare indices calculations when the selected louver position is combined with various sets of luminaire power level combinations. Examples of those glare components are background luminance, luminance of each window patch for DGI calculation, direct and indirect illuminance on the eye surface for CGI calculation and the luminance on the computer screen for GCRT calculation.

4) For each luminaire, n steps of candidate power levels (current power level plus (n-1)/2 steps below and (n-1)/2 steps above the current power level) are identified. Then, from the Luminaire Matrix, each of all nL such combinations are searched out to identify the corresponding illuminance contribution and power consumption along with the glare components (electrical light components) for CGI and GCRT calculations.

5) Final values of glare indices are generated by synthetically combining the glare components - both daylight components and electrical light components - calculated in step 3 and 4 for each louver-luminaires set. This is possible since the pre-calculated glare components are additive in generating the final glare indices. The louver position and the preferable luminaire power levels are identified by selecting the one which maximizes the utility value from all tested louver-luminaires control options. Finally, analog signals are sent to the louver controller and the luminaire ballasts to update the control states of those devices.

91

Simulate Daylight wit h a L ouver An gl e [else] [ a ll l ou ve r a ng le s are cov ere d ] Select Best Louver Angle

Simulate Daylight with Chosen Louver Angle

:DaylightComponent

Se lect a Dimm ing Scheme

Select Dimming Level for a Luminaire

Lookup Luminaire Ma tri x

Identify Ill uminan ce

Identify LbDL

Identify LbCRT

Identify Ed

Identify Ei

Identify Lm ax

Add Ill uminan ce

Add LbDL

Add LbCRT

Add Ed

Add Ei

Add Lm ax

[ el se] [ all luminaire dimming levels are covered ] Get Daylight Components

Add-up Illuminance

Ca lcu la te DGI

Add-up LbCRT

Add-up Ed

Add-up Ei

Add-up Lmax

Evalu ate Co nt rol Op tio ns [else]

:Contro lOpt ionEvaluati onTa ble

[ all luminaire dimming schemes are covered ] Se lect Be st Control Option

Figure 3.37: Activity diagram of HISSTOs daylight responsive lighting control process: UML notation

92

3.5.6.1 Object design of the ManualControl The ManualControl in HISSTO overrides other control modes and doesnt require any prediction or evaluation process to come up with a desired control option. Providing an user with useful information for an informed control decision is therefore critical. To resolve potential conflicts among different users in the same control zone, the implementation of the ManualControl provides three alternative solutions: simple chronological order, user prioritizing, and negotiation. Simple chronological order method takes control command from each user and simply executes them in a chronological order. User prioritizing method implements control action based on the priority given to each user. Negotiations in the ManualControl can be implemented through two negotiation algorithms. Voting is one way where the control action is selected based on the votes from all users. The other negotiation scheme is to take mean value of all requested control state values for each target system. Those two negotiation schemes are only for intra-zone control, so the inter-zone control conflict resolution schemes need to be further studied. Considering the case an user chooses to evaluate every manual control action he/she specifies, the system needs to continuously monitor and log the changing values of the performance indicators for future reference. This is also important for the training of a machine learner designed to capture user control preference. The ManualControl mode is maintained until the user explicitly terminates the mode unless a special event enforces it to be finished.

3.5.6.2 Object design of the ScheduledControl Implementation of the ScheduledControl involves the specification of the conditions-action rules formatted into a table. For example, the louver angle could be specified explicitly based on the outdoor temperature and the time of day as is illustrated in Table 3.11. At every control interval, HISSTO simply checks current conditions and looks up this table to identify and send control command to the Commander object. This ScheduledControl mode can be overridden by any user interruption whenever it is requested. In this control mode, the system calculates and archives the resulting values of the performance indicators mainly for the validation of the specified control schedule.

93

Table 3.11: Louver operation schedule example Outdoor Temperature

>= 76 F >= 76 F >= 76 F <= 70 F <= 70 F <= 70 F

Time
8:00 AM-10:00 AM 10:00 AM-12:00 AM 12:00 AM-3:00 AM 8:00 AM-10:00 AM 10:00 AM-12:00 AM 12:00 AM-3:00 AM

Louver angle (degrees)

45 30 0 105 105 90

3.5.6.3 Object design of the PredictiveControl

Daylight-based dimming of the electrical lights via a predictive control strategy can be implemented in three different ways. The objective of this control strategy is to arrive at a configuration of daylight settings and electrical lighting settings that would accommodate the desired states for both daylight and electrical light systems. The daylight settings are expressed in terms of the position of the external light redirection louvers. The electrical lighting settings are expressed in terms of the dimming level of the luminaires. For example, each of the multiple luminaires in the target control zone can be at one of possible power level states. When any of the hybrid predictors is used for control, only daylight prediction is done by the chosen predictor. All the necessary output variables for electrical light part are, then, separately calculated using a luminaire matrix before final integration.

Predictive Control with the Simulator

The first predictive control approach involves the concurrent assessment of various combinations of both daylight and electrical lighting control variables (Mahdavi et al. 1999). This strategy requires, due to the potentially unmanageable size of the resulting control alternatives, a reduction of the possible number of system states. This is achieved, for example, by dimming the luminaires in groups. Moreover, at each time step, only a subset of possible dimming states are considered for each pair. Let L be the number of luminaires (or luminaire groups) and D the number of dimming states considered for each luminaire. The total number of possible combinations n is then given by the following equation.

n = DL

(3.4)

94

For example, if L = 2 and D = 3, 9 possible electrical lighting control states will result. The concurrent assessment of daylight and electrical light options allow for the real-time incorporation of changes in room and aperture configuration, as well as flexibility in the definition of the dynamic element (such as the position of observer, etc.). However, the limitation of possible dimming options at each time step to the immediate adjacent positions may result in the inability of the search process to transcend local minima and/or maxima.

Predictive control with simulation plus Luminaire Matrix

The second predictive control algorithm involves a sequential approach (Mahdavi et al. 1999). First, the preferable louver position is derived by the daylight simulations. The results are then combined with a preprocessed matrix of various luminaire dimming levels. This Luminaire Matrix can be computed ahead of the real-time control operation based on the assumption that the incident (electrically generated) light at any point in the space can be calculated by the addition of individual contributions of each luminaire. This luminaire matrix needs only be re-generated if there is a change either in the configuration of interior space or in the number, type, or position of the luminaires. The advantage of this approach is the potential of extending the system control state space. The typical time interval between two actuation events (i.e. change of the louver position and/or change of the dimming level of a luminaire) is generally sufficient to allow for the simulator for dealing with a larger number of louver angle options. Combining the results of the selected louver setting with the matrix of electrical lighting states does not require real-time simulation and is thus highly efficient from the view point of computational time. As a result, a larger number of dimming options may be considered and evaluated towards the selection of a preferred combined daylight and electrical lighting settings.

Predictive control with hybrid Predictors

The control approach using any of hybrid predictors is implemented through almost the same process as the simulation plus luminaire matrix control scenario. Instead of using simulator, one of the hybrid predictors is used to predict the values of the daylight performance indicators for each louver control option. The results are then combined with the electrical light evaluation through the Luminaire Matrix look-ups. Each hybrid predictor goes through training or retraining process in case of system or building configuration changes before being used in the continuous control operation.

95

System test & evaluation

4.1

Test bay & control target systems

HISSTOs system test was performed in the Intelligent Workplace (IW), a recently established laboratory at the Carnegie Mellon University campus for demonstration and hands-on study of advanced building systems/technologies and their integration (Hartkopf et al. 1997). The western section of a south bay in IW is dedicated to lighting studies. The test bay features are illustrated through Figure 4.1 to Figure 4.4. This test area is isolated from the rest of IW using white-colored partitions. About 60% of the external wall of the space consists of glazing. This multi-layered enclosure is to reduce thermal loads to enhance air quality, and visual quality. The glazing has low emission coating for heat loss control and 0.3 shading coefficient with high visible transmission. The facade system includes a set of three parallel external moveable louvers which can be used for shading purpose and to a certain degree for light redirection purposes (Table A.3 - Table A.5). An array of 12 illuminance sensors is located along the central axis of this space at the height of about 0.8 m above the floor (Table A.1). Illuminance measurements have been performed intermittently in this test space during the entire year of 1998. For these measurements, eight standard louver positions have been considered as per Figure 4.3. Outdoor daylight conditions are monitored using a total of 11 illuminance and irradiance sensors that are installed on the daylight monitoring station on the roof of the IW. In terms of electrical lighting, the test space is illuminated using four indirect luminaires (Figure A.3) the locations of which are depicted in Figure 4.4 .

Figure 4.1: Intelligent Workplace at Carnegie Mellon University as the system test bed

96

Figure 4.2: HISSTO system test bay at the Intelligent Workplace

Figure 4.3: Illustrative photos showing exterior and interior of the test bay

97

3.8m

L4

L3

4.25m

12 11 10 9 8 7 6 5 4 3 2 1

L1

L2

N 1.6m

L4

L3

.1m

P8: 105 P7: 90 P6: 75 P5: 60 P4: 45 P3: 30 P2: 15 P1: 0

Figure 4.4: Plan and elevation view of the test bay with louver, luminaires, and indoor sensors

98

4.2

Data acquisition for system test

A special instrument having a collective daylight sensing devices named "daylight station" was constructed and installed on the roof top of IW to measure sky conditions. The daylight station includes a diffuse ring which measures diffuse horizontal irradiance by using an adjustable ring designed to block the direct solar insolation during daytime (Figure A.1). Throughout the entire data collection period, the diffuse ring needed to be adjusted every 3-4 days to be tuned for solar path change. The daylight station also measures horizontal and vertical irradiance/illuminance values of the sky for each orientation (Figure A.2). All 23 outdoor daylight sensors as well as 12 indoor illuminance sensors are connected to a couple of PC boards (Table A.6) installed on the host computer so that the data acquisition process could be controlled through the software interfaces implemented as the VITMs (Virtual Instruments for both systems control and monitoring) in LabviewTM environment (Figure A.4 and Figure A.5). The angle of the light redirection louver installed exterior to the test bay was also retrieved through a serial port. Figure 4.5 shows the daylight station installed on the roof of IW.

Figure 4.5: Daylight station on the top of the IW measuring sky condition parameters

99

4.2.1

Analysis of the measurement

Based on the collected measurement data (Table A.8), various analysis were performed to identify the characteristics of both the environmental and the system factors affecting the experiments. Figure 4.6, Figure 4.7 demonstrate the daily and seasonal variations of the local sky condition. Daylight availability in the test bay (Figure A.6 in Appendix A) and the accuracy of the daylight simulations compared to the measurement (Figure A.7 in Appendix A) are also analyzed.
x 10 10 9 8 7 6 global east west south north
4

1000

900

800 global 700 east west 600 W/ m2 500 north south diffuse

5 4 3 2 1 0 6:00 AM

400

300

200

100

9:00 AM

12:00 PM Time

3:00 PM

6:00 PM

0 6:00 AM

9:00 AM

12:00 PM Time

3:00 PM

6:00 PM

Figure 4.6: Sky illuminance and irradiance measurements on a typical clear day (3/13/98)
x 10 14
4

12 Global horiz ontal illum inanc e[lx]

10

0 0 500 1000 1500 2000 2500 3000 3500 4000 D a t a i n s t a n c e w i t h t i m e p r o g r e s s i o n : J u l . , 1 9 9 8 - N o v. , 1 9 9 8 4500

Figure 4.7: Sky illuminance measurement showing daily and seasonal variations

100

Figure 4.8 shows an exemplary daily indoor illuminance profile for all reference points with cyclic louver angle changes. Each line represents different illuminance sensor position in the test bay. The overall daylight pattern during the chosen day shows gradual increase/decrease of the indoor illuminance level with the progress of time. The impact of the cyclic louver angle changes is emerged as the wave-like concave curves across all sensor positions.

7000

6000

5000 Illum inance[lx]

4000

3000

2000

1000

0 0 50 100 150 200 D a ta in s t a n c e w ith t im e p ro g re s s io n : 7 :0 0 A M -4 :0 0 P M 250

Figure 4.8: Indoor illuminance profile on all reference points influenced by the louver angle changes

Figure 4.9 also illustrates the impact of the lover angle changes on the indoor illuminance distribution in the test bay measured at certain point of time. Both sensor-dependent (above) and louver-dependent (below) anaysis show that the impact of the louver angle changes is greater in the afternoon than in the morning. Considering the fact that the windows and the louvers are all facing west side of the test bay, this result can be easily explained. The other distinctive trend is the non-linear pattern of the indoor illuminance profile change when the louver angle is gradually increased. The indoor illuminance level actually decreases up to 30 - 40 degrees of the louver angle and continue to increase after that until the maximum louver angle is reached. This phenomenon can be partially explained by the geometrical configuration of the three louver panel sets which has slight openings between the middle louver panel and the upper or lower louver panel. During the initial louver angle increase operations, each of these openings are gradually covered by the upper louver panel until the angle reaches at the certain degree where the gap between louver panels start continuously growing and accepting more daylight.

101

5000 4500 4000 3500 3000 2500 2000 1500 1000 500 0 S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 Sensor position
P0 P30 P60 P90

5000 4500 4000 3500 3000 2500 2000 1500 1000 500 0 S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 Sensor position
P0 P30 P60 P90

Illuminance[lx]

Indoor illuminance profile at 7:00AM (sensor dependent)

5000 4500 4000 3500 3000 Illuminance[lx] Illuminance[lx] 2500 2000 1500 1000 500 0 P0 P15 P30 P45 P60 P75 P90 P105 Louver position
S1 S3 S5 S7 S9 S11

Illuminance[lx]

Indoor illuminance profile at 1:00 PM (sensor dependent)

5000 4500 4000 3500 3000 2500 2000 1500 1000 500 0
S1 S3 S5 S7 S9 S11

P0

P15

P30

P45

P60

P75

P90 P105

Louver position

Indoor illuminance profile at 7:00 AM (louver dependent)

Indoor illuminance profile at 1:00 PM (louver dependent)

Figure 4.9: Indoor illuminance profiles depending on the sensor positions and louver angles (3/13/98)

4.2.2

Data preparation for testing the predictors

Collected measurement data was filtered and further processed to be used for testing the developed system. There are two different data sets used for the tests. The first group of data sets (D1-D3 in Table 4.1) came from the original measurement after being processed by applying a series of data filters for consis-

102

tency checks described in Table A.7 (Ulah 1996). The second data set group (D4-D6 in Table 4.2) for the system test is obtained by filtering out the data segments of which the measured solar irradiance and illuminance values deviate more than 20 % from the predictions made by the Perez sky model (Perez et al. 1993) used in the simulator, LUMINA (Pal and Mahdavi 1999). Table 4.3 shows another type of data sets generated by the simulator (LUMINA) based on the Pittsburgh weather file (Table A.9). These data sets are prepared mainly for the performance tests of the hybrid predictors such as WFC0NN and WFC1NN trained with weather file-based simulations. All data sets except D3, D6, and WD4-2 were collected while all windows of the test bay were not blocked. These other data sets were obtained in a different building configuration where all windows except two tinted glass windows adjacent to the central door were blocked to reduce incoming daylight for the test purpose.

Table 4.1: Test data sets filtered by the validation criteria (see A.2.1.1)
Data group Date Data set ID Instances 3/33/4 D1-1 453 3/53/13 D1-2 501 3/143/15 D1-3 445 3/163/21 D1-4 391 D 1 (3/3-3/31) 3/223/23 D1-5 477 3/233/25 D1-6 452 3/263/31 D1-7 334 4/14/4 D2-1 513 4/44/5 D2-2 435 D 2(4/1-4/18) 4/64/8 D2-3 468 4/94/13 D2-4 560 4/164/18 D2-5 610 D3(4/19-4/22) 4/194/20 D3-1 259 4/214/22 D3-2 382

Table 4.2: Test data sets within 20 % deviation range from

the Perez model sky prediction

Data group Date Data set ID Instances 3/33/12 D4-1 215 D 4 (3/3-3/31 3/133/19 D4-2 221 3/213/31 D4-3 157 D 5(4/ 1-4/18) 4/14/4 D5-1 115 4/84/18 D5-2 173 D6(4/19) 4/19 D6-1 41

Table 4.3: Neural network training data sets generated by the weather file

based simulations
Data group Instances WD3 (3/1-3/31) 2232 WD4-1(4/1-4/30) 2088 WD4-2(4/19-4/30) 861

103

4.3
4.3.1

Performance test of the predictors

Prediction performance of the LUMINA
In general, a simulation program can be evaluated in three different ways - analytical verification, empirical validation, and comparative study. Table 4.4 shows the characteristics of those three methods in validating a building energy simulation program (Judkoff et al. 1983). Analytical verification aims at perfecting the simulations internal algorithm. Empirical validation checks the simulations prediction capability based on the measurement. Finally, the comparative studies use other simulators in the same domain to benchmark the performance of a simulation program by comparing the outputs based on the same given inputs. .
Table 4.4: Example of typical simulation validation methods Method Analytical verification Validation process Define test cases where the analytical solution is given. Perform predictions for each test case and compared the results with the corresponding analytical solutions. Empirical validation Establish data acquisition instrumentation is for a test cell. Outline necessary data capture to allow careful specification of model input and study model output. After implementing the test, a comparison between measurements and predictions is performed. Comparative studies The test case for this approach should be kept simple to ensure intercode input equivalence. This method can precede the other methods to prove the need for, any subsequent analytical or empirical study and can also be used as a final check against other models already validated.

For the purpose of validating LUMINA, a continuous measurement was performed (Jan. 1997- Dec. 1998) using 17 photometric sensors (Table A.1: for outdoor illuminance measurement) and 6 pyranometers (Table A.2: for outdoor irradiance measurement). 12 indoor photometric sensors are placed inside of the test bay at the Intelligent Workplace (IW). While the angle of the light redirection louver (LRL) was changed based on the incremental cyclic operation schedule, outdoor global horizontal illuminance, global and diffuse horizontal irradiance as well as the vertical illuminance and irradiance for each orientation were measured. Example of the actual inputs to LUMINA are described in Table B.1 - Table B.5. The validation process itself was performed by comparing the simulation result with the corresponding

104

measurement data. To facilitate the comparison, the illuminance values at 12 reference points in the test bay were both measured and simulated for various times/dates and different light redirection louver angles. To represent the sky condition in LUMINA, measured global and diffuse outdoor irradiance values were provided to LUMINAs Perez sky model. Once the sky condition and the louver angle were given for a specific time segment, LUMINA predicted the indoor illuminance distribution profile. For testing LUMINAs performance, a series of simulations were performed with filtered measurement data sets. The input variables included outdoor global horizontal illuminance, global horizontal irradiance and diffuse horizontal irradiance, geometrical and physical properties of the test bay along with time stamp. Output of the simulation included indoor illuminance values on the pre-defined 12 reference points. Figure 4.10 shows a comparison between LUMINAs prediction and the actual measurement on a partly cloudy day. LUMINA performed better on cloudy or partly cloudy days. The prediction error was generally higher on the clear days, especially when the direct sunlight fell onto a subset of the reference points. The overall performance of LUMINA was evaluated by calculating its relative prediction error (Figure 4.11) and charted in histogram (Figure 4.12). The mean relative error used for evaluation was based on the following definition (Mahdavi 1997a).

RE m =

n Ep, i 1 exp -- ln ---------- 1 100 [%] n E m, i i=1

(4.1)

where Em, i measured illuminance on the ith reference point

E p, i

predicted illuminance on the ith reference point

This mean relative error value gives the same weight to the prediction errors that are n times higher or 1/ n times lower than the measurement.

1800 measurement simulation

1600

1400

1200

1000

lx
800 600 400 200 0 0

100

200

300 400 Data index(hourly integrated)

500

600

Figure 4.10: LUMINAs indoor illuminance prediction performance in the test bay

105

80

60

40

20

-20

-40

-60

-80 0

100

200

300 400 Data index(hourly integrated)

500

600

Figure 4.11: Relative error of LUMINAs indoor illuminance prediction

1 000 900 800 700 Frequency 600 500 400 300 200 100 0
20 60 40 -6 0 80 0 0 0 0 0 -1 0 -8 -4 -2 10 0

Re la tive e rror(% )

Figure 4.12: Histogram showing LUMINAs relative indoor illuminance prediction error distribution

4.3.2

Prediction performances of the hybrid predictors

4.3.2.1 Test of the neural networks learning convergence

Various neural networks designed for constructing the hybrid predictors in HISSTO are implemented based on the neural network code developed by Thrun, S. and tested to characterize their learning convergence trends (Figure 4.13). Total 453 training patterns (D1-1: 3/3/98 -3/4/98) are used for this test. The error of each neural network is calculated by the following formula:

( ot o p )

(4.2)

106

where o t is target output, o p is the predicted output, and N is the number of training patterns.

MSC0NN
0.6 0.5 0.4 0.3 0.2 0.1 0

SMC0NN
0.6 0.5 0.4 0.3 0.2 0.1 0

EError rror
500 1000 1500 Training s tep Training step 2000

Error E rror

500

1000 1500 Training step

2000

WFC0NN
0.6 0.5 0.4
0.6 0.5 0.4 0.3 0.2 0.1 0

SMC12NN

Error E rror

0.3 0.2 0.1 0

Error Error 0

500

1000 1500 Training s tep Training step

2000

500

1000

1500

2000

Training step Training s tep

WFC1NN
0.6 0.5 0.4 0.3 0.2 0.1 0

BRIDGENN
0.6 0.5 0.4 0.3 0.2 0.1 0

Error E rror

Error E rror

500

1000 Training step

1500

2000

500

1000

1500

2000

Training step

Figure 4.13: Learning curves of the neural networks in HISSTO

107

4.3.2.2 Test of prediction accuracy

Six hybrid predictors were implemented and tested to evaluate their prediction performance. Although, the data acquisition period covered almost the entire year of 1998, only a limited segment of the total data was used for the test purpose. Some hybrid predictors designed and implemented in HISSTO relied on all 12 indoor illuminance sensors for both training and operation. On the other hand, a hybrid predictor such as WFC1NN used only one indoor illuminance sensor in operation phase, which is a more practical approach in the actual control setting. The speed of a neural networks convergence to optimality was an issue during the test. Optimality is usually an asymptotic result, and so convergence speed is an ill-defined measure. More practical is the speed of convergence to near-optimality. This measure defines how near to optimality is sufficient. A related measure is the level of performance after a given time, which similarly requires that someone defines the given time (Kaelbling 1995).

Figure 4.14 and Figure 4.15 show the accuracy of HISSTOs hybrid predictors in predicting indoor illuminance profile using a part of the filtered measurement data sets (Mar. 3 - Apr. 18, 1998). For the test case 1, two filtered data sets (D1and D2 in Table 4.1) measured for all windows unblocked test bay configuration were used. With test case 2, the same test was done with different data sets further processed by the second filter (D4 and D5 in Table 4.2). In the test case 1, the selected test data sets are divided into 12 partitions to implement sliding time window neural network training and operation scheme for the test. For each time window and each reference point in the test bay, mean relative errors were calculated, then, their RMSs (Root Mean Square) of the indoor illuminance predictions were calculated across all 11 data partitions on which the predictions are made.

Figure 4.14 shows the evaluation result focused on the test case 1. In this test, MSC0NN and SMC12NN perform very well in their predictions (within 5-15% range). With a proper training scheme and the fine-filtered data sets, MSC0NN is capable of predicting indoor illuminance distribution quite accurately since it learns directly from the measurement. Both SMC0NN and WFC0NN, having been trained with simulation outputs based on either the measured sky condition or the weather file, show a similar trend in terms of their prediction capabilities. The fact that those hybrid predictors trained by the simulator are less accurate than the ones trained with the measurement data can be partially explained based on the test data sets being used in each test case. As opposed to the data sets for the test case 2, the data sets for the test case 1 were not filtered to assure a close match between the Perez models prediction of the sky luminance distribution and the actual measurement. This also explains why WFC1NN shows significant performance increase simply by being compensated through the calibration using one indoor illuminance sensor.

108

In the test case 2, as expected, most of the hybrid predictors show improved prediction performance, especially the ones trained by the simulator. All hybrid predictors demonstrate reasonably good prediction performance (within 3-13% RMS error range) across all reference points except the ones close to the window. MSC0NN and SMC12NN perform very well (within 3-7% RMS error range) in their prediction of the indoor illuminance distribution. The simulator and those hybrid predictors trained by the simulator (i.e. SMC0NN and WFC0NN) show a similar prediction trend even though they are slightly less accurate than the ones trained with the measurement data. Among the hybrid predictors tested, WFC0NN turns out to be clearly capable of copying the simulator with sufficient number of training patterns. It is also implied that using actual sky scanner data (instead of using synthetic sky models) can potentially increase the simulators predictive performance as well as those of the other simulationbased hybrid predictors. WFC1NN which is trained by the local weather file-based simulations and calibrated by one indoor illuminance sensor shows an overall performance improvement across all reference points. Selection of the sensor position for calibration is an important factor for an enhanced performance of this predictor.

30 SM MSC0NN 25 SMC0NN WFC0NN SMC12NN 20 WFC1NN

RMS of relative errors [%]

15

10

0 1 2 3 4 5 6 7 8 9 10 11 12

Reference point

Figure 4.14: Different hybrid predictors indoor illuminance prediction accuracy expressed in RMS of relative errors (Test case 1 with D1 and D2 data sets in Table 4.1)

109

30 SM MSC0NN 25 SMC0NN WFC0NN SMC12NN 20 WFC1NN

RMS of relative errors [%]

15

10

0 1 2 3 4 5 6 7 8 9 10 11 12

Reference point

Figure 4.15: Different hybrid predictors indoor illuminance prediction accuracy expressed in RMS of relative errors (Test case 2 with D4 and D5 data sets in Table 4.2)

Figure 4.16 shows the relative prediction performances of all hybrid predictors in HISSTO. Predictions are made for the entire output variables (both reference parameters and performance indicators in Table 3.7) and their mean relative deviations from the simulators prediction are calculated. Simulators output is used for the bench mark because other hybrid predictors are dependent on the simulators prediction for most of the output variables except average illuminance and uniformity.

Test result reveals that the predictive patterns of both SMC0NN and WFC0NN are similar to what the simulator predicts. Even though it is calibrated by a single sensor, WFC1NNs predictive pattern is also similar to those of other simulation-based hybrid predictors. MSC0NN and SMC12NN show higher deviations for certain target variables. Because these two hybrid predictors are heavily sensor dependent (either for training or for calibration), they are affected by the difference between the measured indoor illuminance profile and the simulated one which is propagated to the other target variables by the BRIDGENN. Certain predicted target variables (i.e. solar gain) deviate more from the simulators prediction, which needs to be further investigated. For a meaningful comparison among multiple hybrid predictors, validation of the simulator becomes important, especially for those prediction output variables whose values can be predicted only by the simulator.

110

When the hybrid predictors relative prediction performances of the test case 2 (Figure 4.16-2) is compared to those of the test case 1 (Figure 4.16-1), the difference between the "measurement-based" and the "simulation-based" hybrid predictors predictions is significantly reduced. Since the BRIDGENN is trained by the simulator, even a measurement-based hybrid predictor such as MSC0NN using this BRIDGENN is influenced by the improved simulation performance due to the further filtered sky condition inputs. The graphs in Figure 4.16 are all showing the relative distances of the hybrid predictors predictions from the simulators outputs rather than the relative errors compared to the measurement. Therefore, it is difficult to say that the hybrid predictors in the test case 2 better perform than in the test case 1.
Test case 2
50 SM MSC0NN SMC0NN WFC0NN SMC12NN WFC1NN SM MSC0NN SMC0NN WFC0NN SMC12NN WFC1NN

Test case 1
50

Average of relative deviations from simulation [%]

40

Average of relative deviations from simulation [%]

40

30

30

20

20

10

10

-10

-10

-20 R13

R14

R15

R16

R17

P1

P2

-20 P3 P4 P5 P6 P7

R13

R14

R15

R16

R17

P1

P2

P3

P4

P5

P6

P7

Reference parameters and performance indicator

Reference parameters and performance indicator

Figure 4.16: Different hybrid predictors performance in predicting both reference parameters and performance indicators represented as the averaged relative distances from the simulators prediction

Despite its high predictive accuracy, the need for ever-present multiple indoor illuminance sensors not to mention the difficulty of systematic measurement for the neural networks retraining in operation time makes MSC0NN less practical. This is also true with SMC12NN having the neural network trained to predict simulation errors. SMC12NN also requires multiple simulations every time it is to be deployed. Even without a measurement-based calibration process, the pure simulator performs reasonably well. The simulators memory-intensive and time consuming process is greatly improved in other simulation-

111

based hybrid predictors. For example, SMC0NN approximately inherits the simulators prediction capability.

Among the simulation-based hybrid predictors, both WFC0NN and WFC1NN emerge as the promising ones. They are almost sensor-independent (WFC1NN uses only one indoor illuminance sensor for calibration) while maintaining enhanced prediction capability. This measurement-free architecture also makes them immediately available for operation once they are trained with the training patterns generated by the simulator based on the local weather file. The necessary training patterns can be acquired by performing daylight simulations on weekends at the beginning of each month, which normally takes a day to complete the process. Obviously, all simulation-based hybrid-predictors need a sufficiently accurate simulator to maintain their desirable predictive performance level.

Simple averages of the relative distances from the simulators predictions over the reference parameters and the performance indicators are shown in Figure 4.17 coupled with their standard deviations. Various tested hybrid predictors tested show different trends in this analysis. SMC0NN and WFC0NN were both trained with the data sets generated by the simulator based on the different sources of sky condition data. These predictors are clustered together in terms of their prediction trends and show less deviations from the pure simulators prediction. MSC0NN, SMC1NN, and WFC1NN were trained with either the measurement data or the data generated by the simulator and predict the indoor illuminance profile. They, then used BRIDGENN to predict the reference parameters and the performance indicators. This explains why the prediction pattern of each of those hybrid predictors is similar to that of BRIDGENN. Although BRIDGENN was initially trained with the simulation outputs based on the local weather file, it takes the average indoor illuminance (Em) and the uniformity factor (Uf) calculated from the indoor illuminance profile predicted by the other neural network (i.e. MSC0NN, SMC1NN, or WFC1NN) to generate the final prediction outputs. This clarifies why, when tested with the measurement data sets, BRIDGENN itself and any other hybrid predictor using BRIDGENN show differences in their prediction profiles compared with the other hybrid predictors such as SMC0NN and WFC0NN. This result implies that those hybrid predictors using BRIDGENN share a similar prediction trend although it is not easy way to identify the better performing group of predictors by having no way to measure the values of those performance indicators (i.e. glare indices).

112

100

100

Average & standard deviation of relative distances from simulation[%]

Average & standard deviation of relative distances from simulation[%]

50

50

-50 R13 R14 R15 R16 R17 P1 P2 P3 P4 P5 P6 P7

-50 R13 R14 R15 R16 R17 P1 P2 P3 P4 P5 P6 P7

Reference parameters & preference indicators

Reference parameters & preference indicators

MSC0NN

SMC0NN

100

100

Average & standard deviation of relative distances from simulation[%]

Average & standard deviation of relative distances from simulation[%]

50

50

-50 R13 R14 R15 R16 R17 P1 P2 P3 P4 P5 P6 P7

-50 R13 R14 R15 R16 R17 P1 P2 P3 P4 P5 P6 P7

Reference parameters & preference indicators

Reference parameters & preference indicators

WFC0NN

SMC12NN

100

100

Average & standard deviation of relative distances from simulation[%]

50

Average & standard deviation of relative distances from simulation[%]

P3

50

-50 R13 R14 R15 R16 R17 P1 P2 P4 P5 P6 P7

-50 R13 R14 R15 R16 R17 P1 P2 P3 P4 P5 P6 P7

Reference parameters & preference indicators Reference parameters & preference indicators WFC1NN BRIDGENN

Figure 4.17: Average relative distance and standard deviation of hybrid predictors reference parameters and preference indicators prediction from the simulations (with D1 and D2 data sets in Table 4.1)

113

MS1NN trained with only one indoor illuminance sensor value was also tested to evaluate its prediction performance (Figure 4.18). The test result is slightly better than MSC0NN, possibly due to its significantly reduced neural network output number. Normally, fewer number of output nodes in a neural network means fewer number of the weights the backpropagator should adjust. One of the critical issues with this predictor is to decide which indoor illuminance reference point should be selected. A heuristic rule suggests that the selected reference point better be a meaningful one to the occupant in the target space (i.e. the center of the desk). Fortunately, there is no significant difference in terms of this predictors prediction capability across all tested indoor illuminance reference points except the first and the second one close to the window. Since this predictor needs only one indoor illuminance sensor, it is far more sustainable than MSC0NN except the fact that it can not use such performance indicators as the average illuminance and the uniformity factor, not to mention the others, to identify the best control option.

20

15

RMS of relative errors[%]

10

0 1 2 3 4 5 7 8 9 10 11 12

Indoor illuminance reference point

Figure 4.18: MS1NNs indoor illuminance prediction accuracy with the selected training sensor position

WFC1NN also uses only one indoor illuminance sensor value to calibrate the predictions performed by its component neural network copying the weather file-based simulator. As MS1NN, the selection of a calibration sensor position is an important issue for this predictors implementation. As is shown in Figure 4.19, taking the sensor position either close to the window or near by the opposite wall is better than choosing one of those in the middle. Referring to the pure simulators performance in Figure 4.15, those better-performed illuminance sensor positions are also the ones on which the simulator generates better predictions. It should be noted that WFC1NN uses the simulator to generate indoor illuminance profile

114

before being calibrated by any of those twelve indoor illuminance reference point values.

50
E1 E3

150

RMS of relative deviations from simulation[%]

Em UI DGI GCRT

40

E5 E7 E9 E11

RMS of relative errors[%]

100

30

20

50

10

0 1 2 3 4 5 6 7 8 9 10 11 12

0 1 2 3 4 5 6 7 8 9 10 11 12

Illuminance calibration sensor point a)

Illuminance calibration sensor point b)

Figure 4.19: WFC1NNs indoor illuminance prediction performance (a) and RMS of the predicted performance indicators relative deviations from the simulations (b) with different calibration sensor points

4.3.2.3 Test of decay in prediction performance

One of the critical issues in operating a hybrid predictor is to identify the decay rate of its prediction capability after the training is done. This is necessary especially to determine the hybrid predictors retraining schedule during operation time because the obtained knowledge needs to be updated as time passes. The prediction decay profile of each hybrid predictor has been tested based on the data sets for test case 1 (D1, D2 and D3). The expectation was that a hybrid predictors prediction performance decay rate change due to the gradual alterations of weather pattern and solar position are less than the decay rate change invoked by a sudden building configuration modification (i.e. glazing area change in the test bay).

Figure 4.20 shows HISSTOs five hybrid predictors decay trends in the prediction of the indoor illuminance profile. The test was done by training each of the hybrid predictors only with the first data partition in D1data group followed by a series predictions over the rest of the test data partitions. The entire test data sets cover March 4 -April 22. It was on April 19 when a major building configuration change occurred in the test bay where most of the windows were blocked except two tinted glass windows. SMC12NN and WFC12NN, having calibration mechanisms based on the measurement, performs well all the way up to the end of the test period. WFC1NN shows the least decay because it is always backed up by one indoor illuminance sensor value for calibrating its initial prediction. For the similar reason,

115

SMC12NN performs second best because it compensates the simulators predictions based on the learned error function. When this predictor encounters the window change event, it obviously undercompensates simulators prediction since the actual indoor illuminance suddenly drops and the predictor is not updated to deal with that event properly.

Being trained by the simulator, SMC0NN and WFC0NN behave similarly in terms of their prediction decay profiles. SMC0NN was trained with the simulation outputs based on the first data partition in the first test data set 1 (D1-1) whereas WFC0NN utilized the Pittsburgh weather file-based simulation outputs for its training. Their prediction decay curves show slightly increased overall deviations from the actual measurement compared to those of the other predictors. Since those predictors were initially trained based on the all windows unblocked building configuration, a dramatic increase of prediction errors with D3-1 and D3-2 test data partitions can be easily explained. Because MSC0NN was trained directly with the measured data set, its prediction decay curve shows a fairly stabilized performance across the entire test period except with the last test time window. As is expected, all tested predictors decay curves remain relatively stable even throughout almost a monthly weather pattern and solar position changes up until the building configuration change event....
150

Avaraged abstarct value of relative errors[%]

MSC0NN SMC0NN WFC0NN SMC12NN

100

WFC1NN

50

0 D1-3 D1-4 D1-5 D1-6 D1-7 D2-1 D2-2 D2-3 D2-4 D2-5 D3-1 D3-2

Tested data partition with time progression

Figure 4.20: Indoor illuminance prediction decay curves of the hybrid predictors in HISSTO

Hybrid predictors performance decay trends in the prediction of the reference parameters and the performance indicators are shown in Figure 4.21. Considering the weather and solar position changes during this test period, all tested hybrid predictors perform fairly well until they encounter the building configuration change event at which they show significantly increased deviations. Again, MSC0NN, SMC12NN, and WFC1NN show a similar decay trend to BRIDGENN which is not informed of the

116

building configuration change event. SMC0NNs prediction decay pattern is different from that of WFC0NN, especially for Ed and DGI prediction. This is because SMC0NN only relies on a limited number of training patterns (D1-1) whereas WFC0NN uses much larger number of training patterns covering the entire month (March). .
1000 1000

Average of relative deviations from simulation [%]

900 800 700 600 500 400 300 200 100

MSC0NN
Em

Average of relative deviations from simulation [%]

900 800 700 600 500 400 300 200 100

SMC0NN

Em UI DGI GCRT Q

UI DGI GCRT Q

0 -100 D1-3

0 -100

D1-4

D1-5

D1-6

D1-7 D2-1

D2-2

D2-3

D2-4

D2-5

D3-1 D3-2

D1-3

D1-4

D1-5

D1-6

D1-7

D2-1

D2-2

D2-3

D2-4

D2-5

D3-1 D3-2

Tested data partition with time progression

1000

Tested data partition with time progression

1000

Average of relative deviations from simulation [%]

900 800 700 600 500 400 300 200 100

WFC0NN

Em UI DGI GCRT Q

SMC12NN
Em UI DGI GCRT Q

Average of relative deviations from simulation [%]

D3-1 D3-2

900 800 700 600 500 400 300 200 100

0 -100 D1-3 D1-4 D1-5 D1-6 D1-7 D2-1 D2-2 D2-3 D2-4 D2-5

0 -100 D1-3 D1-4 D1-5 D1-6 D1-7 D2-1 D2-2 D2-3 D2-4 D2-5 D3-1 D3-2

Tested data partition with time progression

1000 1000

Tested data partition with time progression

WFC1NN
Average of relative deviations from simulation [%] Average of relative deviations from simulation [%]
900 800 700 600 500 400 300 200 100
Em UI DGI GCRT Q

BRIDGENN
Em UI DGI GCRT Q

900 800 700 600 500 400 300 200 100

0 -100 D1-3 D1-4 D1-5 D1-6 D1-7 D2-1 D2-2 D2-3 D2-4 D2-5 D3-1 D3-2

0 -100 D1-3 D1-4 D1-5 D1-6 D1-7 D2-1 D2-2 D2-3 D2-4 D2-5 D3-1 D3-2

Tested data partition with time progression

Tested data partition with time progression

Figure 4.21: Decay curves of the hybrid predictors predictions for the reference parameters and performance indicators expressed in terms of their relative distances from the simulation outputs

117

4.3.2.4 Test of change adaptation performance

The change adaptation capability of each hybrid predictor has been also tested using three continuous test data partitions, D2-5, D3-1, and D3-2 (Figure 4.22). Those test data partitions cover only the transition period from the original test-bay window configuration to the one changed. Similar to the other tests, the sliding time window neural network training scheme was used for this test. Test result reveals that the three hybrid predictors such as MSC0NN, SMC0NN, and SMC12NN recover their indoor illuminance prediction capabilities after a single catastrophic deviation shown with the test data partition D3-1. This is because D3-1 and D3-2 include already updated measurement as well as the corresponding simulation result. On the other hand, WFC0NN in the test case 1 shows a significant prediction deviation because of no predictor retraining even after the actual window configuration change event in D3-1. WFC1NN is also influenced by the window configuration change event. As is shown in the test case 2, those prediction deviations are significantly reduced after updating the simulator and retraining the neural networks with the new simulation result.

Test case 1: weather file is not updated

200
MSC0NN SMC0NN WFC0NN

Test case 2: weather file is updated

200
MSC0NN SMC0NN WFC0NN

Average of relative errors[%]

SMC12NN WFC1NN

Average of relative errors[%]

SMC12NN WFC1NN

100

100

D2-5

D3-1

D3-2

D2-5

D3-1

D3-2

Tested data partition with time progression

Tested data partition with time progression

Figure 4.22: Change adaptation performance of the hybrid predictors in their indoor illuminance prediction

Figure 4.23 illustrates how HISSTOs hybrid predictors behave during the window configuration change event in terms of their predictions over the reference parameters and the performance indicators. Those two predictors such as MSC0NN and SMC12NN which once maintain fairly stable indoor illuminance predictions throughout the same change event, now show the increased relative distances from the simulators prediction over a subset of the output variables (i.e. Ed, DGI and Q). This is mainly because of not updated BRIDGENN. Actually, those variables showing more deviation are the ones sensitive to the direct solar component which happens to be cut down dramatically by the window

118

blocking event. SMC0NN shows no difference in both test case 1 and test case 2. WFC0NN and WFC1NN are the ones mostly affected by this event. Again, these deviations are mostly corrected after updating neural networks by the retraining process. WFC1NN is better in dealing with this type of change event than WFC0NN because of its calibration capability using one indoor illuminance sensor. The selected calibration sensor informs WFC1NN of the change event although it still uses the previous version of BRIDGENN to generate the final prediction outputs.

Test case 1: weather file is not updated

Average of relative deviations from simulation [%]
800 700 600 500 400 300 200 100 0 -100 D2-5 D3-1 D3-2

Test case 2: weather file is updated

Average of relative deviations from simulation [%]
900 800 700 600 500 400 300 200 100 0 -100 D2-5 D3-1 D3-2
Em UI DGI GCRT Q

900

SMC0NN
Em UI DGI GCRT Q

Tested data partition with time progression

900 800 700 600 500 400 300 200 100 0 -100 D2-5 D3-1 D3-2 900 800 700 600 500 400 300 200 100 0 -100 D2-5

Tested data partition with time progression

Average of relative deviations from simulation [%]

WFC0NN
Em UI DGI GCRT Q

Average of relative deviations from simulation [%]

Em UI DGI GCRT Q

D3-1

D3-2

Tested data partition with time progression

900 800 700 600 500 400 300 200 100 0 -100 D2-5 D3-1 D3-2 900 800 700 600 500 400 300 200 100 0 -100 D2-5

Tested data partition with time progression

Average of relative deviations from simulation [%]

WFC1NN
Em UI DGI GCRT Q

Average of relative deviations from simulation [%]

Em UI DGI GCRT Q

D3-1

D3-2

Tested data partition with time progression

Tested data partition with time progression

Figure 4.23: Change adaptation profile calculated as the closeness of each hybrid predictors reference parameters and performance indicators prediction to the simulation output

119

Table 4.5 and Figure 4.24 show the evaluation result of HISSTOs hybrid predictors based on the various prioritized criteria. Each number in a cell represents a relative strength of the corresponding predictor in the specified evaluation category. The assignment of numbers are mostly based on the performed in this research. The number in each cell, then is multiplied by Base Number (BN) given in the second column to reflect the priority. Adding up all those number calculated for each cell in a specific predictor column yields the total credit it gets. There are needs for some assumptions and possible subjectivity in this evaluation, yet it shows how each hybrid predictor performs relative to the others.
Table 4.5: Overall evaluation of the hybrid predictors designed in HISSTO Evaluation criteria BN MSC0NN MS1NN SMC0NN WFC0NN SMC12NN WFC1NN

Evaluation criteria Accuracy Agility in prediction Sensor independency in operation Change adaptation Decay resistance Sensor independency in training Total credit

10 9 8 7 6 5 4

7x10 6x9 6x8 2x7 5x6 2x5 2x4 234

1x10 5x9 6x8 5x7 5x6 2x5 4x4 194

7x10 1x9 6x8 6x7 2x6 3x5 5x4 225

7x10 2x9 6x8 6x7 3x6 4x5 6x4 240

7x10 4x9 6x8 2x7 6x6 5x5 2x4 231

7x10 5x9 6x8 5x7 4x6 6x5 6x4 276

300

250

200

Credit

150

100

50

0 MS12NN MSC0NN MS1NN MS1NN SM12NN SMC0NN WF12NN WFC0NN SMC12NN SMC12NN WFC1NN WFC1NN

Predictor

Predictor

Figure 4.24: Overall evaluation of the HISSTOs hybrid predictors in a graphical form

120

4.4
4.4.1

Test of predictive control scenarios

Test of simulation-based control
Three simulation-based control scenarios have been tested. The first scenario uses the simulator to select the best louver angle considering only daylight. The second test is a combined daylight and electrical lighting control scheme with combined daylight and electrical light simulations. The third test case is a simulation plus Luminaire Matrix based daylight and electrical lighting control scheme which dramatically reduces computational time and memory demand.

4.4.1.1 Test of simulation-based daylight control As an initial feasibility test of the simulation-based control approach, automatic determination of the "optimal" louver position (among four standard louver positions) toward fulfillment of daylight related objectives was tested (Mahdavi et al. 2000). Two illustrative objective functions were considered for the test. The first function aims at minimizing the deviation of the average (daylight-based) illuminance level Em in the test space from a user-defined target illuminance level Et (say 500 lx),

Minimize(|EtEm|)

(4.2)

The second objective function aims at maximizing the uniformity of the illuminance distribution in the test space as per the following definition (cp. Mahdavi and Pal 1999):

Maximize U, where U = Em. (Em+Esd)-1 (4.3)

Here Em and Esd are the mean and standard deviation of the illuminance levels measured at various locations in the test space.

The simulation-based louver control scenario in this case followed the GAT approach. At time interval ti, the simulation tool predicts the expected illuminance levels in the space for the time interval ti+1 (test space geometry and photometric properties, as well as the outdoor measurements at time interval ti are used as model input) for the four louver positions selected. Based on the predefined objective functions,

121

the simulator identifies the louver position which is likely to maximize the light distribution uniformity or to minimize the deviation of average illuminance from the target value. To evaluate the performance of this simulation-based control reasoning, The resulting illuminance levels were measured for the four louver positions and for all selected time intervals during the test period, including a total of 28 time instances.

To numerically evaluate the performance of this simulation-based control approach via a control quality index, the measured average illuminance and the uniformity were ranked according to the degree to which they fulfilled the objective functions. 100 points was assigned to intervals in which the simulation-based recommendation matched the position which was empirically found to be the best. In those cases where the recommendation was furthest from the optimal position, 0 was assigned to the interval. Intermediate cases were evaluated as per the Figure 4.25.
100

67

Control Quality

33

Ranked Louver Positions

Figure 4.25: Mapping between ranked louver positions and control quality index

These results (Table 4.6 and Table 4.7) demonstrate an encouraging potential for the feasibility of the proposed approach. The better performance in the case of the uniformity indicator is due to the "relative" nature of this indicator, which, in contrast to the illuminance, is less affected by the absolute errors in the predictions of the simulator.
Table 4.6: Overall evaluation of the daylight control test Control Quality Index Illuminance 73.8 Uniformity 98.9

122

Table 4.7: Percentages of instances with a specific control quality index Control Quality Index Percentage of total instances Uniformity 100 67 33 0 96 4 Illuminance 61 11 17 11

4.4.1.2 Test of simulation-based daylight responsive lighting control Control with the pure simulator

Using only the simulator, the daylight responsive lighting control scenario is tested. The initial systems states with the time stamp serve as the simulation inputs (Table 4.8). To reduce potentially a large number of simulation sessions, only three louver angle (the current angle plus 15 degrees higher and lower than the current angle) are considered for daylight part simulations. For electrical lighting part of the simulations, three luminaire power levels, namely the status quo, the immediate higher state, and the immediate lower state are considered for each of two groups of luminaires (L1+L4 and L2+L3). As a result, a total of 18 simulation runs are necessary to come up with the 10 best control actions presented in Table 4.9.
Table 4.8: Initial state for the inputs to the predictor
Year 1998 Month . 3 Day 14 Hour. 9 Iglob[W/m2] 81 Idiff[W/m2] 78 Eglob[lx] 9,379
n (lvr)[degree]

L1[%] 30

L2[%] 30

L3[%] 30

L4[%] 30

Table 4.9: 10 best control actions suggested by the pure simulator

n+1 (lvr)[degree] L1[%] L2[%] L3[% L4[%] Em[lx]
] 0 15 0 0 15 15 0 0 0 15 20 20 20 30 30 20 40 30 20 20 20 20 30 20 20 30 20 30 40 40 20 20 30 20 20 30 20 30 40 40 20 20 20 30 30 20 40 30 20 20 339 317.667 340 339.833 318.417 318.333 340.667 340.75 340.833 319.583

UE
0.784183 0.788617 0.78515 0.785386 0.790177 0.789567 0.786909 0.786171 0.785798 0.790394

DGI
5.08702 5.07142 5.08702 5.08702 5.07142 5.07142 5.08702 5.08702 5.08702 5.07142

CGI GCRT
0 0 0 0 0 0 0 0 0 0 0.865349 0.870633 0.865349 0.865349 0.870633 0.870633 0.865349 0.865349 0.865349 0.870633

Q[W]
2.29732 2.10193 2.29732 2.29732 2.10193 2.10193 2.29732 2.29732 2.29732 2.10193

P[W]

96 96 120 120 120 120 144 144 144 144

0.681061 0.665948 0.657004 0.656926 0.641822 0.641637 0.632856 0.632771 0.632759 0.61774

123

Control with the simulator plus Light Matrix

Another test is performed using the simulator and a pre-calculated Luminaire Matrix (Table B.6) based on the same initial systems states (Table 4.8). Daylight simulations for eight different louver positions (from 0 to 105 degrees in 15 degrees interval) are performed first. After the most promising louver position is identified by the system (Table 4.10), all 625 different luminaire power level combinations (five discrete power levels for each luminaire) are evaluated to obtain the 10 best dimming options (see Table 4.11). Compared to the simulation only approach, this simulation plus Luminaire Matrix approach is much more efficient toward extending the search coverage in the control option state space.
Table 4.10: Order of the best louver positions suggested by the simulator
n+1 (lvr)[degree]
105 90 75 60 0 45 30 15

Em[lx]
323.833 313.75 296.667 274 259 253 240.25 237.5

UE
0.691845 0.687529 0.679896 0.668466 0.707153 0.698465 0.694442 0.705528

DGI
7.29442 6.76282 6.70231 6.61243 5.86377 6.00177 5.98526 5.89557

CGI
0 0 0 0 0 0 0 0

GCRT
0.974216 0.925105 0.941588 0.954213 0.975549 0.952298 0.992165 0.9907

Q[W]
2.26749 2.10569 2.02388 1.98669 2.29732 1.99742 1.99867 2.10193

P[W] 0 0 0 0 0 0 0 0

0.559583 0.534375 0.494544 0.456758 0.431753 0.421751 0.400497 0.395913

(weight factors: wEm: 0.45, wUE: 0.2, wDGI: 0.05, wCGI: 0.03, wGCRT: 0.1, wQ: 0.12, and wP: 0.05)

Table 4.11: 10 best control actions suggested by the simulator + Luminaire Matrix predictor
n+1 (lvr)[degree] L1[%] L2[%] L3[%] L4[%]
105 105 105 105 105 105 105 105 105 105 105 20 20 20 10 10 10 20 20 20 10 20 20 10 20 10 10 20 10 20 20 20 20 20 20 20 20 20 20 10 10 20 20 10 20 10 10 20 10 10 10 10 20 20 10

Em[lx]
481.917 468.25 467.5 467 453.333 452.583 452.5 452.5 438.917 438.083 438.083

UE
0.81087 0.803117 0.803996 0.801891 0.793781 0.794675 0.79449 0.79449 0.786228 0.786916 0.786916

DGI
8.72461 8.81446 8.81997 8.81757 8.90942 8.91505 8.94012 8.94012 9.00905 9.04048 9.04048

CGI
0 0 0 0 0 0 0 0 0 0 0

GCRT
0.822971 0.838888 0.827625 0.828507 0.845033 0.833438 0.862567 0.862567 0.850581 0.868681 0.868681

Q[W]
0 0 0 0 0 0 0 0 0 0 0

P[W] 46.4 40.6 40.6 40.6 34.8 34.8 34.8 34.8 29 29 29

0.954792 0.920625 0.91875 0.9175 0.883333 0.881458 0.88125 0.88125 0.847292 0.845208 0.845208

4.4.2

Test of hybrid predictor-based control

With the same initial systems state, the alternative control schemes with various hybrid predictors are tested. Table 4.12 shows MSC0NN-based controllers evaluation of each louver position based on the seven performance indicators. Table 4.13 illustrates 10 best daylight responsive lighting control options

124

suggested by the controller using MSC0NN and the Luminaire Matrix look-ups. Table 4.14 and Table 4.15 show the result of WFC1NN-based controller test under the same conditions (Table 4.8). Test results of the other hybrid predictor-based controllers are presented in the Appendix B; Table B.8 Table B.15.
Table 4.12: Order of the best louver positions suggested by the MSC0NN predictor
n+1 (lvr)[degree] Em[lx]
105 90 75 60 45 30 15 0 190.949 187.057 182.505 177.074 170.298 161.137 146.452 100.805

UE
0.702954 0.702124 0.701299 0.700442 0.69931 0.697505 0.694596 0.682252

DGI
4.72866 4.68033 4.6205 4.54948 4.45613 4.35295 4.18524 3.79376

CGI
0 0 0 0 0 0 0 0

GCRT
0.98368 0.985962 0.988443 0.991702 0.995556 1.00118 1.01058 1.04345

Q[W]
1.90946 1.89522 1.88111 1.86159 1.83685 1.8045 1.74962 1.5459

P[W] 0 0 0 0 0 0 0 0

0.42856 0.426448 0.424007 0.421119 0.417149 0.411213 0.401688 0.369602

Table 4.13: 10 best control actions suggested by the MSC0NN predictor

n+1 (lvr)[degree]
105 105 105 105 105 105 105 105 105 105 L1[%] L2[%] L3[%] 20 20 20 10 20 20 10 10 10 10 20 20 10 20 20 10 20 10 10 10 20 20 20 20 10 20 20 20 20 10 L4[%] 20 10 20 20 20 10 10 20 10 10

Em[lx]
348.5 334.833 334.083 333.583 332.75 320.417 319.917 319.167 305.5 289.75

UE
0.854437 0.844884 0.846073 0.844186 0.844139 0.835906 0.833871 0.835154 0.824164 0.811451

DGI
7.45921 7.58194 7.5895 7.5862 7.62746 7.71607 7.71267 7.72047 7.85102 8.03569

CGI
0 0 0 0 0 0 0 0 0 0

GCRT
0.783019 0.802422 0.787762 0.788894 0.810467 0.808058 0.809252 0.794022 0.815359 0.848127

Q[W]
0 0 0 0 0 0 0 0 0 0

P[W] 46.4 40.6 40.6 40.6 40.6 34.8 34.8 34.8 29 23.2

0.62125 0.587083 0.585208 0.583958 0.581875 0.551042 0.549792 0.547917 0.51375 0.483013

Table 4.14: Order of the best louver positions suggested by the WFC1NN predictor
n+1 (lvr)[degree] Em[lx]
105 90 75 60 45 30 15 0 355.326 353.103 350.941 347.359 343.939 338.389 329.055 295.25

UE
0.746651 0.746484 0.74633 0.745619 0.74544 0.74466 0.743364 0.738368

DGI
6.6815 6.63399 6.58683 6.52436 6.46231 6.37001 6.2185 5.76631

CGI
0 0 0 0 0 0 0 0

GCRT
0.911358 0.912167 0.912815 0.914115 0.915258 0.917224 0.920692 0.933347

Q[W]
2.28021 2.27666 2.26605 2.25548 2.24498 2.2276 2.19675 2.08477

P[W] 0 0 0 0 0 0 0 0

0.530025 0.528404 0.52683 0.524105 0.521608 0.517443 0.510435 0.487803

125

Table 4.15: 10 best control actions suggested by the WFC1NN predictor

n+1 (lvr)[degree] L1[%] L2[%] L3[%] L4[%]
105 105 105 105 105 105 105 105 105 105 20 20 10 20 10 20 10 20 20 10 10 20 20 10 10 20 20 10 20 20 20 20 20 20 20 10 20 10 10 10 10 10 10 20 20 10 20 20 20 20

Em[lx]
484.833 499.25 484.333 498.5 483.583 483.5 498 482.75 497.167 482.25

UE
0.835689 0.84194 0.833744 0.842869 0.834702 0.834286 0.840976 0.83521 0.841503 0.83329

DGI
5.95437 5.86478 5.95211 5.86985 5.95729 5.98031 5.86764 5.98552 5.89529 5.98325

CGI
0 0 0 0 0 0 0 0 0 0

GCRT
0.803636 0.799874 0.804443 0.789809 0.794113 0.819778 0.790587 0.809281 0.805352 0.810098

Q[W]
0 0 0 0 0 0 0 0 0 0

P[W] 34.8 40.6 34.8 40.6 34.8 34.8 40.6 34.8 40.6 34.8

0.825736 0.825299 0.824972 0.824922 0.824601 0.824455 0.824168 0.824078 0.823649 0.823319

As is shown in Table 4.16, most controllers that use any of the hybrid predictors suggest similar systems control states for both the louver and the luminaires. The controller that uses only the simulator comes up with different control recommendation due to its limited system control state search space (necessary to reduce computation time).
Table 4.16: Final systems control states (with utility values) suggested by the tested predictors
Predictor type
SM SM + LM MSC0NN SMC0NN WFC0NN SMC12NN WFC1NN 0 105 105 105 105 105 105

n+1[degree]

L1[%] 20 20 20 20 20 20 20

L1[%] 20 20 20 20 10 10 10

L1[%] 20 20 20 20 20 20 20

L1[%] 20 20 20 10 10 10 10

0.68 0.75 0.62 0.77 0.78 0.79 0.83

4.4.3

Test of the convergence time to reach a control action decision

Another test shows the differences of the time necessary for a controller to finish all predictions and evaluations to come up with a control decision. The controller using a hybrid predictor performs best in this test. As is shown in Figure 4.26, the time necessary for finishing one session of simulation was found to be approximately 38 seconds while a neural network took only 0.25 second to perform the same task. The exact numbers could vary depending on various parameters, yet this clearly shows that prediction speed could be enhanced by using neural network-based hybrid predictors trained with the simulator. The average time for an instance of the Luminaire Matrix lookup and control option evaluation was approximately 0.33 second. Table 4.17 shows the time needed to identify the desirable system control states for three controllers using different predictor types. Eight louver positions and five dis-

126

crete power levels for each luminaire are considered in the test. When only the simulator is used, it has to simulate each of 5,000 combined louver-luminaire states separately (equivalent to 190,000 seconds) to finish the task. The system still has to evaluate each of the control options to identify the best, which takes approximately 1,650 seconds (0.33 second, each). When the simulator and the Luminaire Matrix are used jointly, a total of nine simulations are necessary to finish the same task including eight for the identification of the best louver position and one more for calculating daylight glare components based on the determined louver position before being integrated with the ones induced by the electrical light. The total time needed for this method covers luminaire matrix lookups and the evaluation of all 625 luminaire power level combinations. The hybrid predictor- based controller performs also disjointed daylight-electrical light predictions. Except two seconds dedicated to finish the daylight predictions for eight different louver positions, it follows the same process as the simulator plus Luminaire Matrix method. The total time measured reveals that less than a half of the time is necessary for a hybrid predictor method compared to the simulator plus Luminaire Matrix method.

Time for Control Decision [sec]

200000 150000

Prediction Evaluation

100000 50000 0 SM SM+LM WFC0NN+LM Type of Predictor

Time for Control Decision [sec]

1000 800 600 400 200 0 SM+LM WFC0NN+LM Type of Predictor

Prediction Evaluation

Figure 4.26: Time requirements comparison needed for a single control time window

127

Table 4.17: Comparison of the required time for HISSTOs different

controllers
Controller SM SM+LM NN+LM Prediction [sec] Evaluation [sec] 190,000 304 2 1,650 244 244 Total [sec] 191,650 548 246

4.5

Overall evaluation of HISSTO

The evaluation of HISSTO mainly addresses the three different categorized issues - the verification of the thesis hypotheses, fulfillment of the use cases, and those non-functional requirements specified in the requirement elicitation section.

The speed to reach the control decision is significantly increased by using neural networks across all hybrid predictor-based controllers (TH1). In terms of prediction accuracy, any hybrid predictor being trained or calibrated by the measurement data shows an improvement in precision compared to the pure Simulator (TH2). All hybrid predictors except MS1NN cover seven visual performance indicators for the evaluation of the candidate control options by inheriting the simulators modeling capability (TH3). Change adaptation is made possible by updating simulation inputs or having at least one indoor illuminance sensor for constant on-line calibration as is in the case of WFC1NN (TH4). HISSTOs entire design is structured for enhanced modularity and flexibility through a wide use of the software design patterns and component technology so that it can facilitate potential system extensions (TH5).

All use cases involving direct user interactions are covered or at least tested on the internet environment (UC1-UC7).

In terms of fulfilling non-functional requirements, those hybrid predictors in HISSTO can predict within 20 % relative error range by having approximately 400 training patterns along with the encoding/decoding technique devised in this thesis (NFR1). Most hybrid predictors finish the desirable control option selection process under 5 minutes after evaluating eight louver positions and 625 luminaire power level combinations (NFR2). Trained with weather file-based simulations, a hybrid predictor such as WFC1NN can perform well with only one indoor illuminance sensor for real-time on-line calibration (NFR3). Web-based remote access to HISSTO is demonstrated by

128

using LabviewTM and ComponentWorksTM (based on ActiveX technology) off-shelf development environment (NFR4). Future cross-domain interfacing is facilitated by decoupling implementations from their corresponding representations based on the various software design patterns (NFR5).

Table 4.18 shows the summary of HISSTOs evaluation results:

Table 4.18: Assessment of the research outcome including HISSTO implementation ID TH1 TH2 TH3 TH4 Description Prediction speed Prediction accuracy Richness of control criteria Evaluation Compared to pure simulator, hybrid predictors are much faster in their predictions (Table 4.17). Compared to pure simulator, hybrid predictor such as WFC1NN can generate more precise predictions (Figure 4.14, Figure 4.15). Beyond a mere average indoor illuminance based control, HISSTO incorporates glares, heat gain, and energy use into control criteria.

Enhanced adaptation to A pure neural network is expected to perform on-line change adaptation, the changes which is not possible due to the sensor number limit in operation. Manual update is necessary when a change occurs. System flexibility and adaptability Monitoring Manual control Scheduled control Predictive control Predictor update Preference change Predictor parameters change System flexibility is maximized by using design patterns and componentbased object-oriented programing methodology. Designed and implemented Designed and implemented Designed and implemented Designed and implemented. Designed and implemented. Designed and implemented. Designed and implemented Most of measurement-based hybrid predictors and calibrated predictors satisfy 20 % relative error limitation. WFC1NN uses only one sensor to calibrate initial predictions. Web-based monitoring and control are implemented and tested.

TH5 UC1 UC2 UC3 UC4 UC5 UC6 UC7

NFR1 Prediction error

NFR2 10-15 minute time limit All tested hybrid controllers finish the process within 10 minutes. NFR3 Minimum sensors NFR4 Remote access

NFR5 Cross-domain interface API for cross-domain operations needs to be built.

129

Conclusion

5.1

Contributions
The hybrid approach explored in this thesis is a new framework capable of efficiently handling building systems operation while satisfying multiple control criteria, allowing effective adaptation to the potential system or environment changes. This new approach is trying to augment simulations role as a building design evaluation tool to a building operation support tool. This thesis illustrated how computational modeling could be applied to enrich the informational repertoire of systems control operation for lighting. Beyond mere reactive operations based on environmental sensing, model-based building control allowed for proactive evaluation of a richer set of control options. A highly attractive feature of this model-based strategy came from its potential for a transparent and high-level integration of multiple control agenda. A complex control strategy has been formulated to simultaneously address economical and ecological considerations in providing appropriate levels of building visual performance.

On the other hand, simulations capability in building control is proven to be enhanced by being combined with machine learning technique. The hybrid system turned out to be a promising option especially to avoid heavy computational load and to reduce sensor dependency. Reducing computational load in prediction also enables extended search in the system state space within a limited time window. The anticipated synergistic effects between simulation and machine learning have been validated through the design, the implementation and the test of such hybridizations. Maximization of flexibility in control software development and user-system interaction have been also demonstrated by fully exploiting software design patterns as well as the distributed component technology. By performing this research, particularly the following results were achieved:

1) Development of a framework enabling an effective model-based building control. This has been demonstrated in daylight responsive lighting control domain. This process included control instrumentation, setting up an interface for the simulator and the machine learners, and establishing a control option evaluation process (using GAT & BDI method along with the user preference function definition).

2) Prototypical realization of a new perspective on building simulation as a key contributor for enrich-

130

ing control criteria even across multiple domains. This has been demonstrated through the pilot tests in the daylight responsive lighting control domain, whereby glare indices and solar gain were considered as a part of control option evaluation criteria beyond conventional simple illuminance assessment.

3) Extending simulations role in building control by providing a machine learner with prior knowledge to be trained with, reducing its heavy sensor-dependency, and enabling it to capture the behavioral characteristics of complex control parameters.

4) Development and validation of the various ways for on-line hybridization between the simulator and the machine learner to enhance control systems prediction capability in both speed and accuracy. One of these hybridization schemes which uses weather file-based simulations as the source of neural network training knowledge turns out to be especially promising.

5) Exploration of the ways to deal with gradual or radical changes in building systems or the environment. The hybridization approach is shown to be promising in resolving this issue as well.

6) Development of object-oriented and modular control software architecture. The developed system architecture integrates the software components for on-line predictor hybridization, vendor-independent sensing and actuation as well as the location-independent and cross-platform user interactions. This has been done by using various software design patterns in addition to the web-based component technology such as Active XTM.

5.2

Future Research
Future research must address some of the remaining issues. Controlling lighting systems across multiple zones in a building requires extended work. The design and the training scheme for each machine learner in HISSTO needs to be further improved. A machine learner, possibly based on reinforcement learning technique, could learn how to customize personal preference functions for a specific occupant. HISSTOs applicability to the different building control domains also needs to be explored. Considering the scope of the present work, further research must address:

1) Extension of the control scope from one control zone to multiple zones in a building. The control system developed has been tested only with one space of a building although its software design allows to control an entire building. Since a typical building has multiple rooms and control zones, the proposed systems implementation needs to be extended to accommodate multi-zone controls. This also requires

131

the development of a global control algorithm which can handle potential conflicts among different control zones.

2) Identification of possible sensing mechanisms for currently non-measurable control parameters (i.e. glare, solar gain) to validate simulators prediction. If there is a sensor to measure a certain control parameter, it can dramatically enhance hybrid predictors prediction capability. However, in practice, certain parameters such as glare and solar gain are difficult - if not impossible - to be measured with a reasonable cost. New sensing technologies may ease this problem in the future.

3) Improvement of the design and the training scheme for each machine learner in the system to enhance its prediction capability. One example is the way to estimate the variation range of each control parameter within a certain period of time. This has impact on the effectiveness of the neural network training pattern encoding and predicted output decoding, which can greatly influences the prediction performance of the neural network.

4) Development of a machine learner that captures individual users system control preference by observing each users response pattern to the control actions made by the system. Capturing individual user preference is desirable because then the control actions can be customized for each individual user. By recording and interpreting accumulated user interactions with his/her physical environment, a machine learner (possibly, based on reinforcement learning technique) can learn how to customize default preference functions and weight factors of all performance indicators for that specific individual.

5) Database implementation to allow sophisticated and efficient data operations especially for better online machine learner training and trend analysis. Currently the control system is using a file system to organize persistent data storage. The implementation of a DataBase Management System (DBMS) can increase both efficiency and effectiveness of all data operations, especially for the system diagnostics and the trend analysis.

6) Extension of the developed hybrid systems applicability to multiple control domains in a building. The implemented system for this research focused on the visual environment in a building. The same hybrid control system architecture can be used for the other building control domains such as thermal or air flow control. How extensively the system architecture must be restructured and/or extended to cover such other building control domains remains to be further investigated

132

References

Banks, D. L., Olszewski, R. T., Maxion, R. A. (1999), Comparing Methods for Multivariate Non-participant Regression, CMU-CS-99-102, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA.

Barto, A. G. (1990), Connectionist Learning for Control, Neural Networks for Control, The MIT Press, Cambridge, MA.

Brandt, S. G., Shavit, G. (1984), Simulation of the PID Algorithm for Direct Digital Control Applications, Proceedings of the Workshop on HVAC Controls Modeling and Simulation, Georgia Institute of Technology, GA.

Bruegge, B., Dutoit, A. (1999), Object-Oriented Software Engineering: Conquering Complex and Changing Systems, Prentice Hall, New Jersey.

Bruegge, B., OWL project team members (1996), Requirement Analysis Document: OWL Project, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA.

Caroll, J. M. (Ed.) (1995), Scenario-Based Design: Envisioning Work and Technology in System Development, Wiley, New York, NY.

Chang, S., Mahdavi, A. (2001), A Hybrid System for Daylight-Responsive Lighting Control, Proceedings of the Seventh International Building Simulation (IBPSA) Conference, Rio de Janeiro, Brazil, Vol. II. ISBN 85 - 901939 - 3 - 4. pp. 849 - 856.

Clark, J. A. (1985), Energy simulation in Building Design, Adam Hilger Ltd., Accord, MA.

Curtis, P. S. (1996), Experimental Results for a Network-Assisted PID controller, ASHRAE Transactions, 96-21-3.

Douglass, B. P. (1999), Doing Hard time: Development of Real-time systems with UML, Objects, Frameworks, and Patterns, Addison-Wesley, Longman Inc., Reading, MA.

133

Einhorn, H. D. (1979), Discomfort Glare: A Formula to Bridge Differences, Lighting Research & Technology, Vol. 11, No. 2, p. 90.

Flynn, J. E., Kremers, J. A., Segil, A. W., Steffy G. R. (1992), Architectural Interior Systems: Lighting, Acoustics, Air Conditioning, Van Nostrand Reynold, New York.

Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1995), Design Patterns: Elements of Reusable ObjectOriented Software, Addison-Wesley Publishing Company Inc.

Hartkopf, V., Loftness, V., Mahdavi, A., Lee, S., Shankavaram, J. (1997), An integrated approach to design and engineering of intelligent buildings - The Intelligent Workplace at Carnegie Mellon University, in Automation in Construction, Vol. 6, published by Elsevier Science B.V., pp. 401-415.

Hopkinson, R. G. (1971), Glare from Windows, Construction Research and Development Journal, Vol. 2, No. 4, pp. 169-175; Vol. 3, No. 1, pp. 23-28.

Jeannette, E., Curtiss, P. S., Assawamartbunlue, K., Kreider, J. F. (1998), Experimental Results of a Predictive Neural Network HVAC Controller, ASHRAE Transactions: Research.

Judkoff, R. D., Wortman, D. N., ODoherty, R. J., Burch, J. D. (1983), A Methodology for Validating Building Energy Analysis Simulations, SERI (Sustainable Europe Research Institute) Report.

Kaelbling, L. P., Littman, M. L., Moor, A. W. (1995), Reinforcement Learning: A survey, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA.

Kelly, G. F., Park, C., Clark, D. R., May W. B. (1984), HVACSIM+, A Dynamic Building /HVAC/ Control Systems simulation Program, Proceedings of the Workshop on HVAC Controls Modeling and Simulation, Georgia Institute of Technology, GA.

Li, Z. (1997), A Computational Environment for Active Lighting Design, Ph.D. Thesis, School of Architecture, Carnegie Mellon University, Pittsburgh, PA.

Linkens, D. A., Nyongesa, H. O. (1996), Learning Systems in Intelligent Control: An Appraisal of Fuzzy, Neural and Genetic Algorithm Control Applications, IEEE Proc.-Control Theory Appl., Vol 143, No 4. Littlefair, P.J. (1994), A Comparison of Sky Luminance Models with Measured Data from Garston,

134

United Kingdom, Solar Energy Vol. 53, No 4, 1994: pp. 315-322.

Mahdavi, A. (1997a), Toward a Simulation-assisted Dynamic Building Control Strategy, Proceedings of the Fifth International IBPSA Conference, Vol. I, pp. 291 - 294.

Mahdavi, A. (1997b), Modeling-Assisted Building Control, Proceedings of the CAAD Futures '97 Conference (the 7th International Conference on Computer Aided Architectural Design Futures), Munich, Germany, Junge, R. (Ed.) pp. 219 - 230.

Mahdavi, A. (1993), "Open" Simulation Environments: A "Preference-Based" Approach. Proceedings of CAAD Futures '93, Carnegie Mellon University, Pittsburgh, Pennsylvania, USA. pp. 195 - 214.

Mahdavi, A. Pal, V. (1999), Toward and Entropy-based Light Distribution Uniformity Indicator, Journal of the Illuminating Engineering Society, Volume 28, Number 1, Winter 1999. pp. 24 - 29.

Mahdavi, A., Berberidou, L. (1994), GESTALT, A Prototypical Realization of an Open Daylighting Simulation Environment, Journal of the Illuminating Engineering Society of North America, Vol. 25, No 2, Summer 1994. pp. 62 -71.

Mahdavi, A., Chang, S., Pal, V. (2000), Exploring Model-Based Reasoning in Lighting Systems Control. Journal of the Illuminating Engineering Society, Vol. 29, Number 1, Winter 2000. pp. 34 - 40.

Mahdavi, A., Chang, S., Pal, V. (1999), Simulation-based Integration of Contextual Forces into Building Systems Control, Proceedings of Building Simulation '99. Sixth International IBPSA Conference, Kyoto, Japan.

Mahdavi, A., Mathew, P., Kumar, S., Hartkopf, V., Loftness, V. (1995), Effects of Lighting, Zoning, and Control Strategies on Energy Use in Commercial Buildings, Journal of the Illuminating Engineering Society, Volume 24, Number 1, Winter 1995. pp. 25 - 35.

Mistry, S. I., Nair, S. S. (1993), Nonlinear HVAC Computations Using Neural Networks, ASHRAE Transactions 99 (1).

Mitchell, T. M. (1997), Machine Learning, McGraw Hill Inc.

Narendra, K. S. (1990), An Adaptive Control Using Neural Networks, Neural Networks for Control,

135

The MIT Press, Cambridge, MA.

OMG: Object Management Group (1997), Unified Modeling Language (UML) Specification, Ver. 1.0.

Pal, V. (1999), Integrated Computational Analysis of the Visual Environment in Buildings, Ph.D. Thesis, Carnegie Mellon University, Pittsburgh, PA.

Pal, V., Mahdavi, A. (1999), A comprehensive approach to modeling and evaluating the visual environment in buildings, Proceedings of Building Simulation '99, Sixth International IBPSA Conference, Kyoto, Japan, Vol. II. ISBN 4-931416-02-0. pp. 579 - 586.

Perez, R., Seals, R., Michalsky, J. (1993), All-Weather Model for Sky Luminance Distribution - Preliminary Configuration and Validation, Solar Energy Vol. 50, No. 3, 1993: pp. 235-245.

Reynolds, S. (1992), Mechanical and Electrical Equipment for Buildings, John Wiley & Sons Inc.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorenson, W.(1995), Object-Oriented Modeling and Design, Prentice Hall.

Sillion, F. (1991), The State of the Art in Physically-based Rendering and its Impact on Future Applications, Photorealistic Rendering in Computer Graphics, 1991, Springer-Verlag, Berlin.

So, A. T., Chan, W. L., Tse, W. L. (1998), Building Automation on the Information Superhighway, ASHRAE Transactions: Research.

Tellier, P., Bouatouch, K. (1991), Physics Based Lighting Models: Implementation Issues, Photorealistic Rendering in Computer Graphics, Springer-Verlag, Berlin.

Thrun, S. B. (1991), The Role of Exploration in Learning Control, Handbook of Intelligent Control: Neural, Fuzzy, and Adaptive Approaches, Van Nostrand Reinhold, New York, NY.

Ulah, M. B. (1996), International Daylighting Measurement Program-Singapore Data I: Quality of data gathered over a long period, Lighting Research and Technology, Vol 28. No 2.

Webos, P. J. (1992), Overview of Design and Capabilities, Neural Networks for Control, The MIT Press, Cambridge, MA.

136

Appendix

Appendix A: HISSTOs test instrumentation Appendix B: HISSTOs control performance evaluation

HISSTOs test instrumentation

Table of Contents
A.1 Instrumentation ..................................................................................................A1
A.1.1. Sensors ..............................................................................................................................A1 A.1.1.1. Photometric sensor .............................................................................................A1 A.1.1.2. Pyranometer sensor.............................................................................................A1 A.1.1.3. Pyranometer with a shadow ring ........................................................................A2 A.1.1.4. Daylight station...................................................................................................A3

A.1.2.

Actuators ...........................................................................................................................A4 A.1.2.1. Luminaire............................................................................................................A4 A.1.2.2. Light Redirection Louver controller ..................................................................A5

A1.3.

Data Acquisition Hardware...............................................................................................A6 A.1.3.1. Data acquisition PC board ..................................................................................A6

A.1.4.

Control and monitoring hardware interfaces ....................................................................A7 A.1.4.1. Louver and luminaire control interface ..............................................................A7 A.1.4.2. Transducer monitoring interface.........................................................................A8

A.2.

Data collection in the Intelligent Workplace ..................................................A10

A.2.1. Data quality control and measurement samples..............................................................A10 A.2.1.1. Sky measurement data filtering criteria............................................................A10 A.2.1.2. Daylight measurement sample..........................................................................A11 A.2.1.3. Pittsburgh weather file sample..........................................................................A12 A.2.2. Data analysis ...................................................................................................................A13 A.2.2.1. Daylight availability in the IW .........................................................................A13 A.2.2.2. Examples of simulation vs. measurement ........................................................A14

A
A.1
A.1.1

HISSTOs test instrumentation

Instrumentation
Sensors

A.1.1.1 Photometric Sensor

For the system tests, LI-210SATM Photometric Sensor is used for measuring illuminance levels (lux). The LI-210SA Photometric Sensor has been calibrated against a standard lamp and its uncertainty of the calibration is 5 %. Table A.1 shows this sensors specification

.
Table A.1: Specification of the photometric sensor used for the test Sensor attribute Abstract calibration Sensitivity Linearity Stability Response time Description 5 % tractable to NBS 20 A per 100 klux 1% maximum deviation up to 100 klux less than 2% change per 1 year 10 s

Temperature dependence 0.15 % per C maximum Cosine correction Azimuth Tilt Detector Cosine corrected up to 80 angle of incidence 1 % error over 360 at 45 elevation No error included from orientation High stability silicon photo-voltaic detector

A.1.1.2

Pyranometer sensor

This sensor is used for measuring solar radiation received from the whole hemisphere. This sensor uses silicon photo-diode to sense solar radiation. The relative spectral response of the silicon photo-diode is not uniform across the entire solar radiation range. The response is very low at 0.4 m and increases nearly linear to a maximum at about 0.95 m and then decreases almost linear to a cutoff close to 1.2 m. The specification of this sensor is summarized in Table A.2.

A1

Table A.2: Specification of the pyranometer sensor used for the test Sensor attribute Abstract calibration Sensitivity Linearity Stability Response time Description Calibrated against PSP. 5 % maximum, typically 3 % 80 A per 1000 W m
2 2

1% maximum deviation up to 3000 W m less than 2% change per 1 year 10 s

Temperature dependence 0.15 % per C maximum Cosine correction Azimuth Tilt Detector Cosine corrected up to 80 angle of incidence 1 % error over 360 at 45 elevation No error included from orientation High stability silicon photo-voltaic detector

A.1.1.3 Pyranometer with a shadow ring

This instrument is intended to measure the diffused component of solar irradiance from the hemispherical sky received by a horizontal or an inclined plane (Figure A.1). The device is constructed based on the KIPP & ZONENs CM-121 shadow ring guideline. Shadow ring is the mechanism to block the direct solar insolation during daytime based on its adjustment. For this purpose, the axis of the shadow ring is set to be parallel with the polar-axis. As a result, the ring axis maintains the angle same as the latitude of the observation site with the horizontal plane. The shadow ring is supposed to be shifted along the ring axis considering the suns declination. On top of that, the actual sensor should be positioned along the ring axis. Figure A.1 shows the principle of how this device works as intended.

A2

North pole

shadow ring solar insolation in June sensor solar insolation in December

horizontal

Figure A.1: Principle of the shadow ring blocking the direct solar insolation component

The ratio between the ring width and the ring radius is set approximately to 0.185. To adjust the ring position depending on the solar declination, the ring itself has been moving downward or upward at every 3-4 days interval.

A.1.1.4 Daylight station

This device is designed and built for monitoring sky condition all the year round. For both outdoor illuminance and irradiance measurements (horizontal and vertical), total 10 sensors (5 photometric and 5 pyranometer sensors) are placed onto the total five surfaces of a black-painted wooden box surrounded by a hallow rectangular wooden cover for screening ground reflection out. Those 5 surfaces are oriented in such a way that a pair of both photometric and pyranometer sensor on each surface faces either upward, East, West, South, or North. Along with the shadow ring, this simplified version of a sky station has been creating critical data for overall local sky condition throughout the entire data acquisition period (Figure A.2)

A3

photometric sensor

pyranometer

Elevation view

Plan view

Figure A.2: Daylight station for measuring horizontal and vertical irradiance and illuminance in every orientation

A.1.2 Actuators
A.1.2.1 Luminaire Lighting fixture in IW (Figure A.3) is a wall-mounted luminaire with high frequency ballast enabling indirect/direct light distribution and has the fitting of two TC-L 55W lamps. This luminaire unit has a Vshaped extruded aluminum section with ribbed texture along the sides. It has also a matt anodized aluminum reflector for asymmetrical lighting pattern. Wall bracket is for 2-point fitting and compensation for wall angles of 30 . The luminaires dimensions are 275 x 638 x 100 mm. The flux of the lamp is 4800 lm having color rendering index 1 B. This unit is equipped with EVG Zumtobel PC-C ballast having 120W of the connected load and 10 W of the power loss.
180

35

H = 100

270 65

90

L = 637 (mm)

0 (degree)

Figure A.3: Specification of the luminaire installed in the test bay

A4

A.1.2.2 Light Redirection Louver Controller The light redirection louver controller in IW test bay was constructed by Jamieson Shulte, School of Computer Science, Carnegie Mellon University and has the following characteristics (Table A.3):
Table A.3: Design characteristics of the louver controller in the IW test bay Attribute Interface Protection Initialization Communication Format Description 9600bps RS-232 serial interface Watchdog timer protection Hardware-controlled initialization All received command bytes are echoed back to verify that the message has been received. Argument bytes (such as those following the l command) are not echoed. Communication Modes There are two modes of communication, which can be selected by transmitting the ASCII characters 1 or 2 to the sensor. Mode 1: Human interface - the status byte is returned as a binary string such as "00110010", where each bit is represented by the ASCII character 1 or 0. Mode 2: Computer interface - the status byte is returned as the actual byte representing the status value

Table A.4 shows the louvers status bit assignment of the light redirection louver in the IW.
Table A.4: Status bit assignment for checking the louver state in the IW Bit 0 1 2 3 4 5 6 7 louvre is fully open louvre is fully closed louvre is moving open louvre is moving closed louvre is running a program (moving to a preset position) unused controller has been reset, but not initialized controller serial communication mode, 0=hex, 1=ascii Meaning

If bits 4 and 6 are both set, then the louvre is initialized. If the louvre is not initialized, it cannot execute an absolute movement (using the 'd' command) since the current position will be completely unknown. Communication mode (bit 7) should be 0, unless a user is attempting to test the device using a dumb terminal.

A5

Table A.5 shows the control command byte bit assignment of the light redirection louver in the IW.
Table A.5: Control byte bit assignment for controlling the louver in the IW Signal 1 2 a s x o c p Action change to text mode change to byte mode report louver position report interface status clear angle to 0x00 open louver (no program) close louver (no program) stop louver Signal l r t e d g i Action load time-out, 1 byte argument. read time-out, 1 byte returned. load error threshold, 1 byte argument. read error threshold, 1 byte returned. load destination, 1 byte argument. read destination, 1 byte returned. initialize louver hardware.

A.1.3

Data acquisition hardware

A.1.3.1 Data acquisition PC board Data acquisition PC boards is to process sensing and actuation signals. MIO-16E-10TM PC board from National InstrumentTM is chosen for a ISA slot on the control host computer. This board allows the data acquisition capability up to 100 kS/s and shows 12-bit performance on 16 single-ended analog inputs. This board features digital triggering capability, two 12-bit analog outputs, two 24-bit 20 MHz counter/ timers, and 8 digital I/O lines. A brief summary of the devices specification is described in Table A.6.

Table A.6: Specification of the DAQ PC board used

for the system test

Attributes Analog inputs Resolution Sampling rate Input range Analog outputs Resolution Output rate Output range Digital I/O Counter/Timer Triggers Specification 16 SE/8 DI 12 bits 100 kS/s 0.05 to 10 V 2 12 bits 100 kS/s up to 10 V 8 2, 24-bit Digital

A6

A.1.4

Control and monitoring hardware interface

A.1.4.1 Louver and luminaire control interface Data acquisition and control command execution operations are implemented in VIsTM (Virtual Instrument) based on the LabviewTMs G programmingTM language considering its comparability to the various hardware components selected for the system development.

Figure A.4 illustrates the program structure for the louver and the luminaire control in the test bay. Depending on the system control mode, the louver or each luminaire gets converted analog control signal which dictates its system state. Each luminaire is controlled based on a discrete integer value between 0 and 10 for its dimming. The louver state can be set to any of the angles between 0 and 113 degrees except in the automated data acquisition mode where the louver angle is continuously increased in a fixed increment (i.e. 15 degrees) until it hits 105 degrees. The luminaire control signal is passed to the PC board, converted into an analog voltage so that the ballast can set the power level, accordingly. The louver control signal, on the other hand, is passed to the louver motor controller through a RS-232 serial cable. When data acquisition is necessary, the actual data sampling should be done only after the louver reaches the specified target angle. For this, the louver controller does status checks during the louver re-positioning process and initializes louver angle after one cycle of data acquisition is completed.

A7

Figure A.4: Program structure of the luminaires and louver control VI (Virtual InstrumentTM)

A.1.4.2 Transducer monitoring interface Figure A.5 shows the program structure of the data acquisition process. On a daily basis, a user can specify start point and end point as well as the sampling interval of the data acquisition operation using this interface. The program constantly checks the current time in seconds and triggers the defined action when it matches a specific point of the time schedule. Since both the luminaire and the louver dont have sensors attached to them, only photometric and pyranometer sensor values are sampled, logged, and displayed depending on the request. Data sampling rate and buffer size could be customized for each sensor channel. Integration of the sampled sensor values over time is done by calculating average of all those values. When the monitored sensor values are to be logged, the entire sensor values vector is archived in a file with time stamp attached to it.

A8

Figure A.5: Program structure of the data acquisition VI (Virtual InstrumentTM)

A9

A.2

Data collection in the Intelligent Workplace

A.2.1 Data quality control and measurement samples

A.2.1.1 Sky measurement data filtering criteria

To isolate potential errors of in sensor readings, all sensors have been continuously monitored and calibrated. On top of that, Class B category tests proposed by Perez, recommended as the standard by the US Daylight Availability Working Group and US Bureau of Standards, was used to filter the original sky measurement data to avoid inconsistencies (Table A.7). .
Table A.7: Sky condition data filtering criteria Test on irradiance data I g < 1.2I eeo cos ih I D < I eeo I g > 40Wm I d < 1.05I g I g < 1.15 ( I D cos i h + Id ) I v > ID cos iv I g > I D cos i h
2

Test on illuminance data Eg < 1.2E eeo cos ih ED < Eeeo Eg > 150lx Ed < 1.05E g E g < 1.15E D cos ih + E d Ev > ED cos i v Eg > ED cos ih

where
I g : Global horizontal irradiance ( Wm
2

)
2

I eeo : Extra-terrestrial solar irradiance ( Wm I D : Direct normal solar irradiance ( Wm I d : Diffuse horizontal irradiance ( Wm
2

)
2

I v : Solar irradiance on a vertical surface ( Wm

g:

i h : Solar angle of incidence on the horizontal ( )

Global horizontal illuminance ( lx ) Extra-terrestrial solar illuminance ( lx ) Direct normal solar illuminance ( lx ) Diffuse horizontal illuminance ( lx ) Solar illuminance on a vertical surface ( lx )

eeo : D: d: v:

A10

A.2.1.2 Daylight Measurement Sample

Table A.8: Measurement data sample

g 14024 14147 13882 13810 13734 13668 13668 13612 13568 13532 13506 13482 13467 13462 13459 13461 13467 13222 13488 13488 13505 13523 13541 13571 105 41 50 47 44 99 41 49 47 44 5284 5272 95 41 49 47 44 5296 90 41 49 47 44 5307 5900 5916 5929 5952 85 42 49 47 44 5320 5885 84 42 49 47 44 5320 5885 5643 5643 5639 5637 5638 5640 80 41 48 46 44 5206 5803 5525 75 42 49 47 44 5349 5849 5654 5432 5383 5432 5432 5430 5429 5429 5434 70 42 49 47 44 5365 5834 5662 5436 65 42 49 47 44 5382 5820 5670 5438 731 745 764 784 822 822 842 875 914 964 60 42 48 47 44 5402 5812 5681 5442 725 55 42 48 47 44 5426 5798 5694 5445 711 530 541 551 567 592 622 651 651 677 713 762 818 50 43 48 47 44 5456 5788 5710 5452 702 516 45 43 48 48 44 5482 5780 5727 5454 699 509 419 427 439 452 466 487 517 537 562 562 600 637 682 731 40 43 48 48 44 5507 5771 5743 5458 689 505 412 35 43 48 48 44 5533 5765 5759 5464 685 500 407 362 365 374 383 395 410 426 443 473 488 518 518 554 589 629 664 30 43 48 48 44 5554 5757 5776 5471 683 498 403 358 310 313 317 324 334 343 358 368 384 408 413 442 442 469 499 528 553 25 44 48 48 44 5576 5747 5799 5479 685 498 402 354 304 24 44 48 48 44 5576 5747 5799 5479 685 498 402 354 304 270 270 274 278 282 290 299 308 321 331 348 364 370 398 398 422 447 471 491 20 44 48 48 44 5594 5737 5821 5491 694 505 404 355 302 268 15 44 48 49 45 5598 5728 5842 5503 707 513 410 357 300 267 239 240 243 243 248 252 257 263 268 282 296 306 321 332 341 364 364 387 404 424 438 9 44 48 49 45 5601 5722 5864 5516 723 528 420 365 303 268 240 5 45 48 49 45 5725 5763 5950 5609 749 545 435 376 308 271 247 239 234 229 231 235 235 241 244 248 256 264 276 291 300 314 324 332 353 353 374 390 405 420 0 44 48 49 45 5584 5718 5909 5541 783 573 458 396 318 278 252 246 h i j k l m n o p q r s t u v w x y 220 215 210 209 211 213 213 220 223 227 232 242 251 265 275 287 298 308 329 329 350 367 383 394 z 203 199 194 193 196 199 199 205 209 211 220 229 238 250 259 270 279 286 309 309 327 343 361 372 a1 201 196 194 192 194 198 198 203 208 212 221 230 239 252 262 271 279 287 308 308 328 344 360 371 b1 214 208 204 204 205 211 211 219 221 225 236 244 255 267 279 288 300 308 328 328 350 366 383 396

98

11

118

109

98

11

119

110

98

11

117

108

98

11

116

107

98

11

116

106

98

11

115

106

98

11

115

106

98

11

114

105

98

11

114

105

98

11

114

105

98

11

114

105

98

11

113

105

98

11

113

105

98

11

113

105

98

11

113

105

98

11

113

105

98

11

113

105

98

11

111

102

98

11

113

105

98

11

113

105

98

11

114

105

98

11

114

105

98

11

114

105

98

11

114

105

where a: year; b: month; c: day; d: hour; e: global horizontal irradiance; f: diffuse horizontal irradiance; g: global horizontal illuminance; h: louver angle; i: vertical irradiance (east); j: vertical irradiance (west); j:

vertical irradiance (north); k: vertical irradiance (south); l: vertical illuminance(east); m: vertical illuminance (west); n: vertical illuminance (north); o: vertical illuminance (south); p-b1: indoor illuminance values

A11

A.2.1.3 Pittsburgh weather file sample

Table A.9 is a partial sample of Pittsburgh weather file used by the simulator to generate training patterns for the hybrid predictors (i.e. WFC0NN and WFC1NN). When a new month begins or when some change occurs in the building configuration, new simulation sessions are performed based on the proper portion of this weather file to generate new training patterns for those hybrid predictors requiring update.
Table A.9: Local weather file sample (Pittsburgh) Month 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 Day 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 Hour 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 BTU/hr-ft2 (S0-Diff.) 0 0 0 0 0 0 3 23.9 38.8 60.7 121.4 124.9 108.7 97 97.4 71.9 45.1 24.4 2.8 0 0 0 0 0 BTU/hr-ft2 (S0-Tot) 0 0 0 0 0 0 3.4 31.5 98.6 93 160 154 196 126 134 102 52.1 31.4 2.9 0 0 0 0 0 BTU/hr-ft2 (S-Tot) 0 0 0 0 0 0 4.3 29.4 103.7 82.6 135 127.2 180.7 102.2 118.2 89.7 39.3 29 2.2 0 0 0 0 0 BTU/hr-ft2 (E-Tot) 0 0 0 0 0 0 18.2 83.2 211.1 104.1 121.7 84.6 62.9 48.7 46.6 36.7 23.1 14.3 1.8 0 0 0 0 0 BTU/hr-ft2 (W-Tot) 0 0 0 0 0 0 2.5 14.3 27.9 33.2 53.7 57 63.5 70.1 107.4 113.6 62.5 82.2 6 0 0 0 0 0

A12

A.2.2 Data anaysis

A.2.2.1 Daylight Availability in the IW

The western section of a south bay in the IW has been dedicated to the indoor illuminance monitoring task. This area is separated from the rest of IW with white-colored carton boxes. An array of 12 illuminance sensors is located along the central axis of this space at the height of 0.81 m above the floor. Continuous illuminance measurement have been performed between Jan. 1997 and Dec. 1998. During this measurement period, eight standard louver positions have been considered. Figure A.6 shows the percentage of time during which the illuminance levels at the various sensor positions in the test bay were above 250, 500, or 1000 lux (the graphs are based on the time interval from 9 AM to 5 PM and the data collected between March 3 and March 30). Considering only the illuminance criterion, this result would imply that (particularly due to a large percentage of the glazing area) the test bay has almost no need for ambient electrical lighting with only occasional task lighting, if necessary. However, recent occupancy experiences with the issues pertaining to the demand for solar control and glare control emphasize the need for further studies in this domain.

100 90 80 70 60 % 50 40 30 20 10 0 2 4 6 Senso r 8 10 12 above 250 lx above 500 lx above 1000 lx

Figure A.6: Percentage of time during which the average indoor illuminance level at each reference point is more than the specified value

A13

A.2.2.2 Example of simulation vs. measurement

Figure A.7 shows the examples of the measured and the simulated single reference point indoor illuminance predictions during different times of a clear day and a cloudy day.

5000 4500 4000 3500

5000

simulation measurement

4500 4000 3500

simulation measurement

Illuminance [lx]

2500 2000 1500 1000 500 0 6 AM

Illuminance [lx]

3000

3000 2500 2000 1500 1000 500 0 6 AM

9AM

12PM

3PM

6PM

9AM

12PM

3PM

6PM

Time of day

Time of day

a) Simulation vs. measurement on a clear day

b) Simulation vs. measurement on a cloudy da

Figure A.7: Comparison between the measurement and the simulation for the time dependent change of a single indoor illuminance value on a clear day (a) and a cloudy day (b)

A14

HISSTOs control performance evaluation

Table of Contents
B.1 Preparation of the Predictors.............................................................................B1
B.1.1. Instantiation of the knowledge source ..............................................................................B1 B.1.1.1. Simulation input data..........................................................................................B1 B.1.2. Luminaire Matrix sample..................................................................................................B3

B.2.

Test of HISSTO as a lighting control system ....................................................B5

B.2.1. Control system performance test with different predictors...............................................B5

B
B.1

HISSTOs control performance evaluation

Preparation of the predictors

B.1.1 Instantiation of the knowledge source

B.1.1.1 Simulation input data Table B.1-Table B.5 show a subset of the input values to the LUMINA simulation program used for a series of experiments performed in the test bay at the Intelligent Workplace. Describing both internal and external surfaces and windows along with their physical properties was the main part of inputs to LUMINA. Considering the geometrical sophistication of the test bay configuration, certain level of simplification has been applied to those non-critical building components to reduce the complexity and the time needed to finish necessary simulations. Reference points, site information, viewer information (for glare calculations), and luminaire information were added to the inputs. All dimensions describing the locations and sizes of the building components and systems are based on the metric scale. Light redirection louvers were described as the dynamic external surfaces which change their states in operation time. Part of the inputs to LUMINA came from the measurement done with the daylight station on the roof-top of the IW. .
Table B.1: Properties of the internal surfaces in the test bay
a 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 b 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 1.8 3.8 3.8 0 0 0.4 0 0.4 0 0.4 0.4 3.8 2.8 0 0 0 0.5 0.5 0.5 d .8 4.3 4.3 -0.3 2.7 0 -0.3 4.3 4.6 0 4.3 0 1.5 -0.3 0 1.6 -0.3 4.6 -0.3 e 0.9 0 3.1 0 0 0 0 0 0 3.1 3.1 3.1 4.7 3.1 0 0.8 2.4 2.4 2.4 f 1.4 3.8 3.8 0 0 0.4 0 3.8 0.4 0.4 3.8 0.4 3.8 0 3.8 3.8 0.4 0.4 0.5 g 0.8 0 0 1.6 4.5 0 -0.3 4.3 4.6 4.3 4.3 0 1.5 4.6 0 1.6 -0.3 4.6 4.6 h 0.9 0 3.1 0 0 3.1 3.1 0 0 3.1 3.1 3.1 4.7 3.1 0 0.8 2.4 2.4 2.4 i 1.4 3.8 3.8 0 0 3.8 0.4 3.8 0.4 2.8 3.8 2.8 3.8 0.4 3.8 3.8 0.4 0.4 0.5 j 0.8 0 0.9 1.6 4.5 0 -0.3 4.3 4.6 1.5 1.5 0.9 0.9 4.6 4.3 2.7 4.6 -0.3 4.6 k 1.2 3.1 4.7 0.9 0.9 3.1 3.1 3.1 3.1 4.7 4.7 4.7 4.7 3.1 0 0.8 2.4 2.4 2.6 l 1.8 3.8 3.8 0 0 3.8 0.4 0.4 0 2.8 2.8 3.8 2.8 0.4 0 0 0.5 0.5 0.5 m 0.8 4.3 0.9 -0.3 2.7 0 -0.3 4.3 4.6 0.9 1.5 0.9 0.9 -0.3 4.3 2.7 4.6 -0.3 -0.3 n 1.2 3.1 4.7 0.9 0.9 0 0 3.1 3.1 4.7 4.7 4.7 4.7 3.1 0 0.8 2.4 2.4 2.7 o 0.8 0.7 0.7 0.7 0.7 0.7 0.7 0.7 0.7 0.7 0.7 0.7 0.7 0.4 0.3 0.3 .7 0.7 0.7 p 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 q 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 t 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

B1

Table B.2: Properties of the external surfaces outside of the test bay
a 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 b 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -0.88 -1.30 -0.88 -1.30 -0.88 -1.30 0 -0.2 -0.3 -0.3 c d 4.6 0.3 1.4 2.9 4.0 4.6 1.6 4.6 -2 -2 -2 -2 -2 -2 -2 -0.3 -2 -2 e 2.2 0.9 0.9 0 0.9 0.9 0 0 2.69 2.69 2.25 2.25 1.80 1.80 3.1 2.9 3.1 3.1 0 0 0 0 0 0 0 0 -0.88 -1.30 -0.88 -1.30 -0.88 -1.30 -0.3 -0.2 -0.3 -1.1 f g -0.3 -0.3 0.3 1.4 2.9 4.0 -0.3 2.7 6 6 6 6 6 6 -2 4.6 6 -2 h 2.2 0.9 0.9 0 0.9 0.9 0 0 2.69 2.69 2.25 2.25 1.80 1.80 3.1 2.9 3.1 3.1 0 0 0 0 0 0 0 0 -1.30 -0.88 -1.30 -0.88 -1.30 -0.88 -0.3 -0.2 -1.1 -1.1 i j -0.3 -0.3 0.3 1.4 2.9 4.0 -0.3 2.7 6 6 6 6 6 6 6 4.6 6 6 k 3.1 2.2 2.2 2.2 2.2 2.2 0.9 0.9 2.69 2.69 2.25 2.25 1.80 1.80 3.1 3.1 3.1 3.1 0 0 0 0 0 0 0 0 -1.30 -0.88 -1.30 -0.88 -1.30 -0.88 0 -0.2 -1.1 -0.3 l m 4.6 0.3 1.4 2.9 4.0 4.6 1.6 4.6 -2 -2 -2 -2 -2 -2 6 -0.3 -2 6 n 3.1 2.2 2.2 2.2 2.2 2.2 0.9 0.9 2.69 2.69 2.25 2.25 1.80 1.80 3.1 3.1 3.1 3.1 o 0.13 0.13 0.12 0.13 0.12 0.13 0.7 0.7 0.24 0.46 0.24 0.46 0.24 0.46 0.6 0.6 0 0.6 p 0 0 0 0 0 0 0 0 0.1 0.1 0.1 0.1 0.1 0.1 0 0 0.4 0 q 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 t 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

where a: number of vertices; b: number of holes; c: x coordinate of the 1st vertex; d: y coordinate of the 1st vertex; e: z coordinate of the 1st vertex; f: x coordinate of the 2nd vertex; g: y coordinate of the 2nd vertex; h: z coordinate of the 2nd vertex; i: x coordinate of the 3rd vertex; j: y coordinate of the 3rd vertex; k: z coordinate of the 3rd vertex; l: x coordinate of the 4th vertex; m: y coordinate of the 4th vertex; n: z coordinate of the 4th vertex; o: reflectance: p: transmittance; q: diffuseness of reflectance; r: specularity of reflectance; s: phone exponent for specular reflectance; t: diffuseness of transmittance; u: specularity of transmittance; v: phong exponent for specular transmittance

Table B.3: Properties of the windows installed on the western facade of the test bay
a 0 0 0 0 0 0 b -0.3 -0.3 0.3 1.4 2.9 4.0 c 2.2 0.9 0.9 0 0.9 0.9 0 0 0 0 0 0 d e 4.6 0.3 1.4 2.9 4.0 4.6 f 2.2 0.9 0.9 0 0.9 0.9 0 0 0 0 0 0 g h 4.6 0.3 1.4 2.9 4.0 4.6 3.1 2.2 2.2 2.2 2.2 2.2 i 0 0 0 0 0 0 j k -0.3 -0.3 0.3 2.9 2.9 4.0 l 3.1 2.2 2.2 2.2 2.2 2.2 m 0.7 0.62 0.62 0.7 0.62 0.7 n 0.84 0.61 0.71 0.5 0.71 0.61 o 0.13 0.13 0.12 0.13 0.12 0.13

where a: x coordinate of the 1st vertex; b: y coordinate of the 1st vertex; c: z coordinate of the 1st vertex; d: x coordinate of the 2nd vertex; e: y coordinate of the 2nd vertex; f: z coordinate of the 2nd vertex; g: x coordinate of the 3rd vertex; h: y coordinate of the 3rd vertex; i: z coordinate of the 3rd vertex; j: x coor-

B2

dinate of the 4th vertex; k: y coordinate of the 4th vertex; l: z coordinate of the 4th vertex; m: transmittance; n: frame factor; o: reflectance
Table B.4: Site properties of Pittsburgh
a 72 b 80.22 c 40.5 d 373.3 .2 e f 283

where a: longitude; b: longitude of time meridian; c: latitude; d: height above sea level; e: ground reflectance; f: building azimuth

Table B.5: View point specification for glare calculation

a 1.6 b 1.2 1.1 c 0 d e 180

where a: x coordinate of the eye location; b: y coordinate of the eye location; c: z coordinate of the eye location; d: altitude of the line of sight; e: azimuth of the line of sight

B.1.2 Luminaire Matrix sample

Table B.6 shows a sample of the Luminaire Matrix used for electrical lighting calculation in HISSTO.

B3

Table B.6: Luminaire Matrix sample

where, Li: dimming level (0 -10) of the ith luminaire in the test bay, Ei: illuminance value of the ith reference point, MOi: total solid angle (modified) subtended by the window at the eye, Lsi: luminance of the ith glare source (luminaire) in the field of view, Lb: background luminance, Ed: direct illuminance on the vertical surface of the eye, Ei: indirect illuminance on the vertical surface of the eye, Lmax: luminance value of the patch on the computer screen having maximum luminance

B4

B.2

Test of HISSTO as a lighting control system

B.2.1 Control system performance test with different predictors

Based on the predictions made by the different predictors, multiple instances of the daylight responsive lighting control scenario were tested with the same initial systems states illustrated in Table B.7.
Table B.7: Initial systems states for testing HISSTOs various controllers
Year 1998 Month 3 Day 14 Hour 9 Iglob 81 Idiff 78 Eglob 9379 Louver 0 L1[%] 30 L2[%] 30 L3[%] 30 L4[%] 30

There were two sub-test categories: The first sub-test category establishes the rating of the different louver angles based on their predicted daylight performances. The second sub-test focuses on the 10 best control actions for both the louver angle and the luminaire dimming levels suggested by each predictor. Most predictors suggested similar system control states for the louver and the luminaires in the test bay. Since pure simulation method has limited louver state search range bounded between one step below and above the initial state, it could not pick up the angle more than 15 degrees as the desirable louver state unlike the other predictors. The result of this test is illustrated through Table B.8 to Table B.15.

B5

Table B.8: Order of the best louver positions suggested by the SMC0NN predictor
n+1 (lvr)[degree]
105 90 75 60 45 30 15 0

Em[lx]
287.94 285.643 282.719 278.879 274.48 268.341 258.004 221.631

UE
0.694243 0.694345 0.694345 0.694447 0.694548 0.69465 0.694854 0.695669

DGI
5.69578 5.69578 5.70983 5.72392 5.72392 5.75212 5.78046 5.89488

CGI
0 0 0 0 0 0 0 0

GCRT
0.951931 0.951931 0.952111 0.95229 0.95229 0.952648 0.953007 0.954444

Q[W]
2.27312 2.25197 2.22415 2.18997 2.14646 2.09116 1.99775 1.66999

P[W] 0 0 0 0 0 0 0 0

U 0.472181 0.471109 0.469647 0.467803 0.465678 0.462685 0.457668 0.440089

Table B.9: 10 best control actions suggested by the SMC0NN predictor

n+1 (lvr)[degree]
105 105 105 105 105 105 105 105 105 105 L1[%] L2[%] L3[%] L4[%]

Em[lx]
432.667 418.25 431.917 446.333 417.75 403.333 431.417 417 416.917 402.5

UE
0.813567 0.805872 0.814496 0.821825 0.80374 0.795618 0.812422 0.804694 0.804283 0.796135

DGI

CGI

GCRT
0.812854 0.81773 0.800836 0.796577 0.818703 0.823905 0.801768 0.806306 0.83727 0.843112

Q[W]

P[W]

20 20 20 20 10 10 10 10 20 20

20 10 10 20 20 10 20 10 20 10

20 20 20 20 20 20 20 20 10 10

10 10 20 20 10 10 20 20 10 10

6.61017 6.71686 6.6162 6.51194 6.71416 6.82349 6.61357 6.72034 6.74782 6.85802

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

40.6 34.8 40.6 46.4 34.8 29 40.6 34.8 34.8 29

0.766531 0.766502 0.766144 0.766096 0.765705 0.765587 0.765359 0.765323 0.765133 0.765007

B6

Table B.10: Order of the best louver positions suggested by the WFC0NN predictor
n+1 (lvr)[degree]
105 90 75 60 45 0 30 15

Em[lx]
297.019 290.262 282.719 274.48 265.037 244.361 253.727 239.842

UE
0.703764 0.703558 0.703352 0.703147 0.702941 0.71556 0.702941 0.703558

DGI
8.3377 7.98815 7.597 7.16993 6.6815 5.15554 6.09928 5.39348

CGI
0 0 0 0 0 0 0 0

GCRT
0.927389 0.930783 0.934378 0.938526 0.943769 0.949254 0.949966 0.957695

Q[W]
2.42033 2.36755 2.31251 2.24498 2.16976 1.86992 2.07204 1.94126

P[W] 0 0 0 0 0 0 0 0

U 0.475736 0.472897 0.469735 0.466285 0.462334 0.457793 0.457648 0.453133

Table B.11: 10 best control actions suggested by the WFC0NN predictor

L1[%] n+1 (lvr)[degree] 105 105 105 105 105 105 105 105 105 105 20 20 20 20 10 10 10 10 20 20 L2[%] L3[%] L4[%]

Em[lx]
426.833 441.25 440.5 454.917 426.333 411.917 425.583 440 425.5 411.083

UE
0.818311 0.825616 0.826647 0.8336 0.816065 0.808351 0.817124 0.82446 0.816726 0.808987

DGI

CGI

GCRT
0.801449 0.797103 0.785329 0.781553 0.802397 0.807031 0.790258 0.786238 0.820447 0.825686

Q[W]

P[W]

10 20 10 20 20 10 10 20 20 10

20 20 20 20 20 20 20 20 10 10

10 10 20 20 10 10 20 20 10 10

6.76375 6.65591 6.662 6.55665 6.76102 6.87156 6.76727 6.65934 6.79505 6.90648

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

34.8 40.6 40.6 46.4 34.8 29 34.8 40.6 34.8 29

0.775349 0.775302 0.774936 0.774814 0.77453 0.77449 0.774168 0.774128 0.77398 0.773935

B7

Table B.12: Order of the best louver positions suggested by the SMC12NN predictor
n+1 (lvr)[degree]
105 90 75 45 15 30 60 0

Em[lx]
251.72 242.075 226.748 188.546 168.034 175.724 206.999 162.861

UE
0.694691 0.689732 0.68146 0.698065 0.700491 0.692283 0.669116 0.69062

DGI
5.57059 5.44754 5.2603 4.69242 4.43301 4.5377 5.02701 4.43301

CGI
0 0 0 0 0 0 0 0

GCRT
0.957514 0.96261 0.970907 0.986152 0.996717 0.994012 0.982542 1.00177

Q[W]
2.00078 1.97074 1.91807 1.87551 1.8152 1.82598 1.85054 1.73433

P[W] 0 0 0 0 0 0 0 0

U 0.504403 0.495861 0.481992 0.475341 0.466608 0.464592 0.462857 0.456912

Table B.13: 10 best control actions suggested by the SMC12NN predictor

n+1 (lvr)[degree]
105 105 105 105 105 105 105 105 105 105 L1[%] L2[%] L3[%] L4[%]

Em[lx]
381.167 395.583 394.833 409.25 380.667 366.25 379.917 394.333 379.833 365.417

UE
0.814181 0.822253 0.823395 0.831026 0.811761 0.803172 0.812938 0.82105 0.812459 0.803841

DGI CGI

GCRT
0.810143 0.805083 0.792073 0.787722 0.811197 0.816627 0.79774 0.793079 0.831319 0.837503

Q[W]

P[W]

20 02 20 20 10 10 10 10 20 20

10 20 10 20 20 10 10 20 20 10

20 20 20 20 20 20 20 20 10 10

10 10 20 20 10 10 20 20 10 10

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

34.8 40.6 40.6 46.4 34.8 29 34.8 40.6 34.8 29

0.793685 0.793612 0.793277 0.793116 0.792826 0.792796 0.792499 0.792434 0.792341 0.792305

B8

Table B.14: Order of the best louver positions suggested by the MS1NN predictor
n+1 (lvr)[degree]
105 90 75 60 45 30 15 0

Em[lx]
113.463 109.949 106.18 101.463 95.8041 87.8937 75.6861 40.7427 x x x x x x x x

UE

DGI
x x x x x x x x

CGI
x x x x x x x x x x x x x x x x

GCRT

Q[W]
x x x x x x x x

P[W] x x x x x x x x

U 0.189143 0.183285 0.177002 0.169139 0.159705 0.146519 0.126169 0.0679181

Table B.15: 10 best control actions suggested by the MS1NN predictor

n+1 (lvr)[degree]
105 105 105 105 105 105 105 105 105 105 L1[%] L2[%] L3[%] L4[%]

Em[lx]
275.25 266.083 265.75 265.333 264.75 257.25 256.583 256.333 256.167 255.833

UE
0.800104 0.797484 0.795959 0.798804 0.796171 0.795107 0.793098 0.79202 0.795998 0.794446

DGI

CGI

GCRT
0.42798 0.433364 0.420493 0.42135 0.436882 0.439186 0.425766 0.412473 0.426661 0.413354

Q[W]

P[W]

50 50 50 40 50 50 50 50 40 40

50 50 40 50 50 50 40 30 50 40

50 50 50 50 40 50 50 50 50 50

50 40 50 50 50 30 40 50 40 50

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

116 110.2 110.2 110.2 110.2 104.4 104.4 104.4 104.4 104.4

0.137653 0.133068 0.132902 0.132693 0.132401 0.128651 0.128317 0.128192 0.128109 0.127942

B9