Draft ACEEE paper - May 14, 1996 - LBL-38827 1Remote Building Monitoring and ControlFrank Olken Chuck McParland Mary Ann Piette Dale SartorStephen SelkowitzLawrence Berkeley National LaboratoryBerkeley, CA 94720July 18, 1996SYNOPSISWe discuss a system for remote monitoring andcontrol of heterogeneous commercial buildingHVAC systems via the Internet using CORBAprotocols atop TCP/IP.ABSTRACTThis project is intended to develop a proto-type system which would permit remote monitor-ing and control of multiple commercial buildingsacross the Internet from a single control center.Such a system would be used by operators of mul-tiple buildings, such as school districts, govern-ments, universities, large retailers, utility compa-nies, building management �rms, et al.We anticipate that such a system would reducethe labor costs of building monitoring and con-trol and thereby permit more extensive monitor-ing and control of building HVAC and lightingsystems. We estimate that this will generateimprovements in building energy e�ciency of 15percent on average.Phase I of the project involves the following com-ponents:� A gateway between the building energy mon-itoring and control system (EMCS) andthe Internet. This gateway is intended topresent a common interface to the remotebuilding monitoring control system via theCommon Object Request Broker Architec-ture (CORBA) protocols.� Development of applications-level object

speci�cations for HVAC objects, e.g.,chillers.� A remote building monitoring and controlcenter (RBMCC) which will provide data vi-sualization, database management, buildingenergy simulation, and energy usage analysistools.� Deployment and testing of the system atSoda Hall, University of California Berkeley.Control functionality is being deferred to PhaseII. The initial applications will be data visualiza-tion and regression analysis of power usage of thechiller/cooling tower systems.OVERVIEWThis paper is comprised of the following sections:background, what, why, how, related work, de-sign issues, acknowledgements.BACKGROUNDBuildings consume one-third of all energy in theUnited States at a cost of $200 billion per year,with $85 billion per year for commercial build-ings. A large amount, perhaps half of this energyis wasted compared to what is cost-e�ectivelyachievable. Much of this waste is related to ourinability to optimally control and maintain to-day's complex building systems. Recent build-ing performance case studies suggests that typ-ical savings of about 15%, and as much as 40%

Draft ACEEE paper - May 14, 1996 - LBL-38827 2of annual energy use can be gained by compiling,analyzing, and acting upon energy end-use data(Herzog and Wheeler, 1992, Claridge et al, 1994).The applications under development for theRemote Building Monitoring and Operations(RBMO) project are based on utilizing existingcapabilities of, and expanding upon informationavailable through Energy Management ControlSystems (EMCSs). Several studies have exploredEMCS monitoring capabilities (Heinemeier, Ak-bari, and Tseng). EMCSs for commercial build-ings are readily available. There are over 150EMCS manufacturers (EUN 1994). About 50%of all buildings over 45,000 meter2 (500,000 sq.ft.) have an EMCS, and they are present innearly all large o�ces (EIA 1992). For buildingsbuilt since 1992, almost 50% of the oor area isin buildings with EMCSs.Today's EMCS have been built primarily forcontrol. EMCSs are special-purpose comput-erized control systems, programmed to operatebuilding equipment such as chillers, fans, pumps,dampers, valves, motors, and lighting systems.EMCSs are installed for many di�erent purposessuch as: controlling equipment, alerting opera-tors to possible equipment malfunction, main-taining comfortable conditions, and permittingmodi�cation of control speci�cations.EMCSs typically monitor building operationaldata such as damper positions, set points, statevariables of the working uids, and equipmentstatus. They are not generally used to monitorelectrical demand. In some cases, more accuratesensors may be needed for diagnostics than aretypically included in an EMCS. For example, totrack chiller e�ciency, a very accurate measure-ment of the temperature drop across and water ow rate through the chiller is needed. The sen-sors in a typical EMCS may not be su�cientfor this calculation. We have added additional ow sensors and better temperature sensors tothe cooling plant at Soda Hall where we are con-ducting our research.ASHRAE has, after a nine year e�ort, recentlyapproved a new communications standard, forbuilding automation systems { The Building Au-tomation and Control Network (BACnet) Stan-dard. This standard views the HVAC (Heating,Ventilating and Air Conditioning) system as a

collection of objects. However, the standard doesnot (yet) include standard applications-level ob-jects such as chillers or cooling towers. Thisproject addresses the de�nition of such objects.We expect that BACnet will shortly be used toconnect building gateways to EMCSs.WHATFunctionalityThis project is developing software systems tosupport remote monitoring and control of mul-tiple buildings, i.e., HVAC, lighting, etc., acrossthe Internet, using CORBA - Common ObjectRequest Broker Architecture protocols. It is in-tended to work with heterogeneous EMCS andHVAC systemsThe ultimate users of the system will beowner/operators of multiple buildings e.g., U.S.General Services Administration, school districts,universities, retail chains, banks, property man-agement �rms, ESCOs, utilities, et al.Research Project GoalsThe research project has two primary goals:demonstration of technical feasibility of the pro-posed design, and demonstration of the utility ofthe system.Technical feasibility of remote monitoring isscheduled for �scal year 1996, remote control in�scal year 1997. A single EMCS is slated for �s-cal year 1996, with additional EMCS's in �scalyears 1997 and 1998. Remote model-based con-trol is slated for �scal year 1998. Note that �scalyear 1996 ends Sept. 31, 1996.Demonstrations of utility (improved energy e�-ciency) include statistical analysis in �scal year1996, simulation in �scal year 1997, and model-based control in �scal year 1998.WHYClose attention and careful analysis of the datafrom building EMCS's typically a�ords many op-portunities to improve building operations, re-

Draft ACEEE paper - May 14, 1996 - LBL-38827 3sulting in improvements to occupant comfort andreductions in energy use.However, for most buildings, such close atten-tion and analysis are not undertaken, due to lackof appropriate software, operator training, sta�,or due to inaccurate or malfunctioning sensors.Remote building monitoring o�ers the possibil-ity to reduce the labor costs involved in monitor-ing/analyzing EMCS's by spreading such laborcosts over a large number of buildings. This willalso make it economically feasible to employ ex-pert HVAC engineers.Use of the Internet has two aspects: use of the In-ternet communications protocols, and use of theactual Internet network.Use of Internet networking protocols permits ac-cess to a wide variety of a�ordable interoperablehardware and software from many di�erent ven-dors over many di�erent media. Internet mar-kets are huge, in the millions of users, hencevendors can readily amortize development costs.In contrast, proprietary protocols typically en-tail more expense, because of lack of competitionand because development costs are being amor-tized over smaller markets. Industry speci�c pro-tocols, such as BACnet, fall in between these twoextremes. Internet protocols are clearly the mostpopular for wide area networking applications.Use of the Internet network permits users to sharethe costs of a common communications infras-tructure. When building automation applica-tions can share existing Internet infrastructure,substantial savings over telephone dial-up sys-tems are possible (Haberl 1996). The Internetalso o�ers the prospect of inexpensive access tohigh bandwidths when needed - e.g., for remotevideo surveillance for security, �re, or remote di-agnostics. Finally, the Internet o�ers a reliable,redundantly connected, backbone. The down-side of using the Internet is the necessity of morestringent security precautions, discussed furtherbelow.HOWIn this section we brie y describe the followingcomponents of the project:� Gateway systems in each building

� Applications-level object speci�cations� Remote monitoring and control facility� Prototype deployment and testingMore detailed discussion of design issues followsin a later section.Each building will have a building gateway sys-tem to interface between the building energymonitoring and control system (EMCS) and theInternet. This gateway is intended to mask theheterogeneous EMCS and HVAC systems by pre-senting a common interface to the remote build-ing monitoring control system via the CommonObject Request Broker Architecture (CORBA)protocols (discussed further below). One suchgateway system will be installed in each build-ing. Ultimately, we would expect that EMCSvendors would incorporate this software into theEMCS. The gateway systems will be built usingthe Windows NT operating system, running onPC's. (See Figure 1.)We are developing applications-level object spec-i�cations, written in the CORBA Interface Def-inition Language (IDL), for HVAC objects, e.g.,chillers, for use in the gateway protocol. Thesespeci�cations are strongly in uenced by the workof the Industry Alliance for Interoperability ondeveloping a common data model to describebuildings. This is described further below.We are also developing a remote building mon-itoring and control center (RBMCC) which will(ultimately) provide data visualization, databasemanagement, building energy simulation, and en-ergy usage analysis tools. The remote monitoringfacility will be comprised of two components:� A data acquisition and database manage-ment server which will be built on a Unixsystem.� Several PC-based analysis workstations,which will be used for data visualization, sta-tistical analysis of the data, and simulation.A prototype system is under development for acase-study site on the U.C. Berkeley campus.Soda Hall is a 10,000 meter2 (109,000 sq. ft.)building on the U.C. Berkeley Campus. It housesstudents, faculty, and a host of computers as the

Draft ACEEE paper - May 14, 1996 - LBL-38827 4CORBATCP/IP

CORBATCP/IP

Building EMCS

Gateway Building EMCS

Gateway

CORBATCP/IP

Data VisualizationStatistical AnalysisSimulation

RemoteFacility

GUI

Internet

GUI

System ArchitectureRemote Building Operations

DBMS

Figure 1: System Architecture. Notes: GUI = Graphical User Interface

Draft ACEEE paper - May 14, 1996 - LBL-38827 5home of the Electrical Engineering and Com-puter Science Department. The building wasconstructed in 1993 and fully occupied in 1994.The cooling plant contains two 220 ton screwchillers on a primary loop that maintains con-stant ow through the chillers. The secondaryloop has variable frequency drives to allow thechilled water ow to be matched to the cool-ing loads called for at the cooling coils. Twotwo-speed cooling towers provide condenser wa-ter to the chiller and additional cooling units dis-tributed through the building's interior computercenters.Soda Hall has been the focus of another LBNLresearch project to evaluate information transferthrough the entire building life cycle, and the useof tools to improve overall building performance.Soda Hall was chosen because of our familiaritywith it, its proximity, Internet access, and be-cause of the cooperation of the facilities manage-ment sta�, occupants and control system vendor.Applications SoftwareThe RBMO applications are designed aroundproviding the following three capabilities:� Archiving historical data in a database� Providing standard graphics for performanceanalysis� Performing a series of regressions and statis-tical analysis techniques to (1) de�ne \base-line" conditions and (2) evaluate energy per-formance after a retro�t, operations andmaintenance changes, occupancy changes, orfor historical tracking.We envision that applications software - statisti-cal analysis, visualization, simulation - will runprimarily in the PC-based analysis workstations,running Windows NT. This approach was chosento permit use of applications software developedfor the Windows and Windows NT operating sys-tems.Initial applications will focus on the use of stan-dard regression models to model energy usage asa function of weather. Such regression can beused to estimate the energy savings produced by

retro�ts, in the presence of confounding changesin weather. We are initially concerned with theenergy usage of the cooling plant.The whole-building and cooling plant monitoringat Soda Hall consists of a few dozen sensor points(out of 1500 total sensor points in the building)that cover whole-building electricity use, weathervariables, plus chiller power and cooling towerstatus, and several temperatures and water owrates. We added several power and ow meters,and temperature sensors to the cooling plant tocompare them with the original EMCS sensorsand augment information that was not availablefrom the EMCS.We are developing a standard set of performancetracking plots to allow users to view archiveddata with a user-friendly menu. This will in-clude daily (24-hour) load shapes of 5-minuteoperating data for all values; weekday, weekend,and and weekly load shapes (hourly data); andmonthly average load shapes. The chiller andcooling plant analysis will consist of plots suchas power versus cooling load (kW versus tons)and e�ciency versus load (kW/ton versus tons).The applications are intended for use by an re-mote expert. Most of the focus on the graphicsis on energy use. However, the capability will ex-ist for the user to look at detailed data such astime series of cooling plant water temperaturesor cooling tower fan start-stop intervals. Theconcept is to provide a tool for a remote userwho might be responsible for tracking the per-formance of building systems at multiple loca-tions. The menu of standard graphs are designedto allow the user to easily view the most criti-cal, macro-level performance data, while provid-ing additional means for more detailed analysisof micro-level data. In other words, the scriptedgraphs should allow the user to answer the ques-tion, \is the building and cooling plant operatingwell?"The applications will also include a regressionmodel tool known as EMODEL (Kissock et al.1994). The purpose of the model is to allow oneto evaluate the energy savings from an interven-tion, such as a change in the control set pointsor a retro�t. EMODEL is a tool for buildingenergy use data, with single, multiple, and lin-ear regression algorithms, including change-point

Draft ACEEE paper - May 14, 1996 - LBL-38827 6and bin analysis. Four-point change-point mod-els are useful when there is simultaneous heatingand cooling in a commercial building (Ruch &Claridge 1992).In �scal year 1997 we plan to integrate some con-trol capabilities into the system. This will requirethe availability of a secure version of CORBA,not yet readily available. We also plan to inte-grate HVAC simulation tools, such as SPARK,into the analysis.In FY 98 we plan to integrate model-based con-trol into the system.RELATED WORKRemote MonitoringA number of related R & D projects are under-way: ElectroTek, Texas A & M, Ryerson Poly-technic, RPM Associates, EDS.These project vary in their purposes, communica-tions technologies, building interfaces, databasemanagement systems, etc.ElectroTek Corp. has a research project (Elec-trotek 1996) focused primarily on remote mon-itoring over the Internet of electric powerquality and usage. It employs a data ac-quisition/database server running a relationaldatabase, connected to gateway machines viaTCP/IP over the Internet. The gateway commu-nicates using the newly developed Power QualityData Interchange Format (PQDIF). The gatewaymachines in turn use broadband communicationsto monitor devices within the building, either tocircuit monitoring equipment or another PC in-terfaced to additional power quality monitoringinstruments. PC's runningWindows NT are usedfor all of these machines about both the buildingand remote sites.The Texas A & M system (Haberl 1996) providesfor remote monitoring over the Internet of dataloggers recording electric energy usage at variousbuildings on the campus and elsewhere. They useprinter control protocols over TCP/IP. Printercontrollers are then used to interface data loggersto Internet. This approach is quite inexpensive.A relational DBMS is used. Statistical analysis isdone with SAS and custom analysis software. Se-

curity is provided via IP address �ltering - whichcan be defeated by address spoo�ng. The remotedata acquisition and database server runs on aUnix server.Ryerson Polytechnic has developed a Unix-basedremote monitoring system, Axon, (Ott 1996) forBell Canada. The goal of the system was toprovide a common user interface for a numberof di�erent EMCS systems, to reduce trainingcosts. The system talks to 18 di�erent types ofEMCS systems over serial lines using the pro-prietary protocols of the EMCS vendors. Thesystem has a centralized data acquisition anddatabase server and supports multiple remotefront ends (user interface machines) communicat-ing via UDP.RPM Associates has developed a system (Lake1996a; Lake 1996b) for remote power qualitymonitoring which uses SNMP (Simple NetworkMgt. Protocol) (Cohen 1995; Rose 1995) RMON(Remote Monitoring Protocol) over UDP/IP. Itcan be used across LANs or the Internet.EDS (Electronic Data Systems) is exploring thedevelopment of remote environmental and powermonitoring systems for Federal Avition Adminis-tration (FAA) facilities based on SNMP (akin toRPM Associates).A number of commercial remote building moni-toring systems are also available. Typically, theseemploy the EMCS vendor's proprietary protocolto speak to each EMCS. Dial-up telephone linesare typically used for communications. An ex-ample is the Measuring and Monitoring Services,Inc. system which uses dial-up phone communi-cations between a central PC-based data acquisi-tion system and data loggers in various buildingsto collect lighting system usage and power usagedata (Bowman 1996).Building Life-Cycle InformationSystem (BLISS)The remote monitoring project will be integratedinto the systems being developed as part of alarger e�ort at LBNL to develop tools to im-prove the transfer and usefulness of building per-formance data throughout the building life cy-cle. A tremendous amount of information andknowledge is lost as buildings move from design

Draft ACEEE paper - May 14, 1996 - LBL-38827 7to commissioning and operations. This loss re-sults in buildings that are not operated, con-trolled, or maintained as intended. We are ex-amining problems associated with current build-ing information transfer methods and prelimi-nary designs for Building Life-cycle InformationSystems (BLISS). The remote monitoring toolsthat are the primary subject of this paper are acrucial part of the proposed life-cycle informationsystems. They are needed to compile the time-series data for ongoing performance tracking andevaluation. See (Selkowitz, et al. 1995) and(Mills 1995) for overviews of the BLISS project.See (Piette, 1996) for a discussion of buildingcommissioning aspects of BLISS.Industry Alliance for Interoperabil-ity (IAI)The Industry Alliance for Interoperability(IAI 1996) is a consortium of architec-tural/engineering/construction (AEC) softwarevendors (e.g., Autodesk and Bentley Systems)who are working on developing a standard datamodel for description of buildings. The datamodel is intended to be used by architecturaland engineering design tools, construction costestimation software, construction schedulingsoftware, etc.The IAI data model is now being written inEXPRESS, the modeling language adopted bythe STEP/PDES product data interchange stan-dards community. IAI and STEP are attemptingto coordinate their e�orts.Part of the IAI data model encompasses HVACdescription. Our data modeling e�orts, whilemore limited than IAI, give careful considerationto compatibility with the IAI model.DESIGN ISSUESThe central design issues to be confronted inbuilding a remote building monitoring and con-trol system are:� Choice of distributed computing environ-ment - CORBA vs. OLE vs. SNMP� DBMS selection

� When to transpose data� When to bind the database schema� How to perform applications integration andinterface to DBMS� Construction of common abstraction of mul-tiple EMCS and HVAC SystemsOLE vs. CORBAThe distributed (a.k.a. networked) version of Mi-crosoft's OLE (Object Linking and Embedding)software is the principal competitor to CORBA(Common Object Request Broker Architecture)as a general purpose object-oriented distributedcomputing environment. See Table 1 for a sum-mary of the di�erences between the two systems.CORBA o�ers two critical advantages for ourproject. It is readily available now, whereas dis-tributed OLE is not. (Note that the single systemversion of OLE is widely used.)Secondly, the CORBA object is fairly standardand supports multiple inheritance, whereas OLEdoes not support even single inheritance. In-heritance permits one to specify that centrifugalchillers are a subtype of chiller and hence inheritall of the properties (and operations) of genericchillers. This permit much more concise descrip-tions of object classes. Multiple inheritance per-mits an object class, such as automobile, to in-herit properties (and operations) of multiple par-ent classes, e.g., motor vehicles (engine size, num-ber of cylinders) and wheeled vehicles (numberof axles, number of wheels, wheel diameters).Multiple inheritance permits further economiesin class speci�cations. Note that multiple inher-itance of CORBA meshes well with similar fa-cilities in the programming language C++ andmost object-oriented DBMSs. Also, the IAIdata model, known as IFC (Industrial Founda-tion Classes) employs multiple inheritance. ThusCORBA is more compatible with the IFC thanOLE.See (Orfali, Harkey & Edwards 1996) for an ex-tensive comparison of CORBA and OLE. Alsosee (Ben-Natan 1995) and (Mowbray & Zahavi1995) for detailed discussions of CORBA. Seealso the Object Management Group's web page(OMG 1996).

Draft ACEEE paper - May 14, 1996 - LBL-38827 8Feature OLE CORBAVendors Microsoft Sun, HP, DEC, IBM, Iona, Ex-persoft, et al.Interoperability Moot NowOperating Systems Windows, NT Unix, Windows, NT, QNX, VX-works, et al.Distributed Version Promised soon NowObject Model Lacks inheritance Multiple inheritanceIncompatible with IFC Compatible with IFCStandards Org. Microsoft Object Management GroupDesktop Presence Strong WeakCompound Docs OLE OpenDocSecurity Unknown Standard promised, some nowLanguages C++, C, Visual Basic C++, C, Smalltalk, JavaEvent services Yes YesScalable Unknown YesPerformance Poor in alpha VariesCommunications Synchronous Remote Proce-dure Call Synchronous Remote ProcedureCallMulti-threaded Unknown Most implementationsTable 1: Comparison of OLE and CORBAOLE, CORBA CoexistenceGateways exist between CORBA and OLE fromseveral vendors. These gateways will generateOLE Automation Interface from CORBA IDL(Interface De�nition Language). Note that theCORBA IDL can be used for interface de�nitionin either single machine or distributed setting,i.e., the use of CORBA IDL does not dictate thepartitioning of programs the among machines.CORBA vs. SNMPSNMP is the Simple Network Management Pro-tocol, developed by the IETF (Internet Engineer-ing Task Force) for use in Internet based net-works for network management. It typically usesthe connectionless UDP/IP datagram protocol,rather than the connection-based TCP/IP. Thereis wide vendor support for network devices. It isobject oriented, however the protocol only allowsset/read individual objects vs. invocation of arbi-trary object operations. Hence, this simple pro-tocol will likely require substantially more net-work messages than CORBA to accomplish simi-lar operations. CORBA permits one to de�ne ob-ject operations which involve reading and/or set-

ting multiple object parameters. Thus, in princi-ple CORBA should o�er better performance.There is (as yet) little use outside of networkmanagement, although we are beginning to seeits use for power monitoring, especially in unin-terruptible power system (UPS) environments. Ituses the ISO protocol ASN.1 for data exchange.The C programming language is the preferredembedding. SNMP Version 2 includes securitymechanisms for both authentication and encryp-tion. See (Rose 1994) for a more detailed discus-sion of SNMP.CORBA is typically used atop TCP/IP proto-col. C++ is the preferred embedding. There isbroad (>500) vendor support. It is applicableacross many types of distributed applications. Itprimarily o�ers synchronous RPC (remote proce-dure call) across heterogeneous platforms. Thereare some asynchronous event services (messages).It uses the new IIOP protocol (atop TCP/IP)for interoperability/data exchange. It allows ar-bitrary object operations. It allows \brokering ofrequests" - clients need not know the location ofthe server they require - the broker will �nd itand if necessary activate the server. There is nosecurity as yet - the Object Management Group

Draft ACEEE paper - May 14, 1996 - LBL-38827 9(OMG) is working on the standard.It should be possible to construct gateways be-tween CORBA Systems and SNMP systems.Note that CORBA functionality largely sub-sumes SNMP functionality (except (as yet) forsecurity).CORBA vs. DDEDDE is the Dynamic Data Exchange protocolde�ned by Microsoft Corp. in the mid to late1980's. This protocol was originally used withina single processor. Subsequently Wonderwareand Microsoft introduced networked versions ofDDE which ran atop TCP/IP. The protocol usesASCII (i.e., text) encoding to pass commandstrings (and arguments) to programs. It is notobject-oriented. The syntax and semantics areentirely de�ned by the applications. Each appli-cation must parse the incoming command strings.Hence, it has a reputation for being slow. Mi-crosoft has obsoleted it with the development ofthe OLE protocol.The attraction of the networked DDE protocol isthe wide availability of support for DDE amongcommercial software vendors, especially those inindustrial control systems.CORBA o�ers a much richer object model andobject services, whereas DDE only o�ers onlytransmission of uninterpreted strings. CORBA'suse of binary encodings leads to better perfor-mance. CORBA Interface De�nition Languagecan be used to specify object operators, largelyavoiding the need for parsing command strings.DBMS Selection CriteriaThe bulk of the data we are collecting will be timeseries, e.g., of temperatures, power usage, etc.Although the raw data may be irregular time se-ries, we will transform these to regular time seriesfor analysis. Regular time series assume periodictemporal sampling. Hence, our most importantcriterion for selection of the database manage-ment system (DBMS) is its suitability for timeseries data and queries.It is possible to support time series data on any ofseveral DBMS: relational, object-oriented (OO),

or hybrid object-relational. Use of relationalDBMS for regular time-series data typically o�ersmediocre performance, weak support for opera-tions such as smoothing and calendars. Object-oriented DBMSs permit the implementation oftime-series data collections with better supportfor calendars, smoothing, etc. However, no com-mercial object-oriented DBMS yet provides o�-the-shelf support for time series data, so the usermust code his own. In contrast, one of the hybridobject-relational DBMSs, Illustra (Illustra 1996),o�ers built-in time-series support.Most of the data which are not time series arebuilding description data - i.e., CAD (Com-puter Aided Design) data describing the phys-ical con�guration of the building, HVAC sys-tem, and the EMCS system. Object-orientedDBMSs (OODBMSs) are generally much bet-ter suited to CAD data than relational DBMSs(RDBMSs), both because the object data modelis more closely matched to CAD data modelingrequirements, and because OODBMSs typicallyo�er much better performance for CAD applica-tions. Indeed, CAD applications were the pri-mary drivers for the development of OODBMSs.Ideally, we would like to use a single DBMS forall BLISS activities, including the building moni-toring data. Particularly during the design phaseof the building, the CAD data management willrequire extensive support for versioning of thedesign data, and support for long transactions(so-called check-in/check-out) to support designactivities.Other criteria for selection of the DBMS includefacilities for integration with popular statisticspackages. Usually, this is available for the ma-jor relational DBMSs, but not object-orientedDBMSs.CORBA interfaces, for at least some of the com-mercial CORBA implementations, are availablefor several object-oriented DBMS, but not typi-cally for the relational or hybrid DBMSs.Support for client-server DBMS con�gurations istypically available for all of the DBMSs. This willallow us to move the analysis and visualizationcodes to the PC-workstations while maintainingthe database on a robust database server.The ability to support distributed data man-agement, i.e., querying across multiple database

Draft ACEEE paper - May 14, 1996 - LBL-38827 10servers, and support for updates across multipledatabase servers are also important for the designphases of BLISS. It is expected that, for largecommercial buildings, there will be multiple de-signers (architects, structural engineers, mechan-ical engineers, et al.) at diverse sites, each withtheir own building representation, who will needto work together.Data TranspositionOur telemetry data on the building state are ini-tially available as cross-sectional data, i.e., wesample the entire building state periodically, typ-ically at 1-5 minute intervals. However, typicalanalyses use only a few state variables, but willtypically want to look at long time-series of eachsuch state variable. Thus it is expedient for anal-ysis purposes to have the stored data in a sepa-rate time-series for each state variable.The question then arises as to when and wherethe data are to be transposed from cross-sectionalto time-series storage formats. This can be doneat collection time, analysis time, or some inter-mediate time.Transposition at collection time slows the col-lection process, but speeds the analysis phase.Transposition at analysis time permits very fastdata collection, but slows the analysis phase.Transposition at intermediate times permits bothvery fast data collection and fast analysis. How-ever, the software architecture becomes morecomplex and costly to implement and maintain.Transposition can also occur either at the gate-way machines, the database server, or the analy-sis workstations.We have chosen to transpose the data at thedatabase server as it is collected. This will gen-erate at least one disk I/O operation per datapoint monitored for each sampling period. Ourrationale for this choice is that this appears tobe the simplest architecture to implement, andshould have adequate performance for our pro-totype system. If we were to scale our systemto much larger collections of buildings we wouldperhaps need to adopt a scheme of intermediatetime transposition.

Schema Binding TimeAnother major design issue is when and howtightly to bind the user's database schema (i.e.,database design) to the database schema used bythe database management system. This is analo-gous to an architect deciding whether to incorpo-rate the current o�ce layout as either structuralor nonstructural walls, modular walls, or cubi-cles. The schema binding time decision involvestradeo�s among the performance of the system,di�culty in implementing the system, and the exibility in adapting the system to changes inthe building design or EMCS con�guration. Notethat we distinguish here between the user's DBschema, and the schema employed by the DBMS.These need not be (and often are not) the same.In EMCS parlance the user's schema is often re-ferred to as the naming convention for sensorpoints.Alternatives include:� a �xed compile-time complete binding of theuser's schema into the DB schema,� a completely dynamic run-time binding ofthe user's schema into a generic DB schema� binding of the user's schema at system ini-tialization time.Compile-time binding involves direct binding ofthe user's objects and attributes in the databaseschema and code. Here the user's schema and theDB schema are virtually identical. The advan-tages of this approach include fast performance,simple architecture and implementation. Thedisadvantage is that it is di�cult to modify, andmay require the system developer to supply theuser with source code for the system.The dynamic schema binding approach entailsthe use of a very generic DB schema, to which theuser's schema is bound at run-time. Thus the DBschema might consist of a basically single table,with �elds for object name, attribute name, at-tribute value, and timestamp. The user's schemathus becomes data in the generic DB schema.This approach o�ers enormous exibility, stan-dard DB schema and code at all sites. However,this is often at the expense of performance penal-ties. Furthermore, such designs often ignores the

Draft ACEEE paper - May 14, 1996 - LBL-38827 11type system of the underlying DBMS, requiringthat all attributes be stored as text strings.Another common strategy, particularly in dataacquisition and control systems, is to bind theuser's schema to the database schema at systeminitialization time. The advantages are good per-formance, and reasonable exibility. The disad-vantages are more complex design than compile-time binding, and less exibility than dynamicbinding.Gateway SystemIn each building, a gateway system will mediatebetween the EMCS and the remote monitoringand control system (via the Internet). It will in-terface to the local EMCS via proprietary pro-tocols (or possibly BACnet). Typical EMCSsare hierarchical control systems comprised of ahost processor, which support the user interface,and several control processors on a local area net-work, which run local control loops and interfaceto several multiplexors each. We would preferto connect our gateway machine to the host pro-cessor, in order to minimize potential con ictsarising from concurrent access to the control pro-cessors by the gateway and host processors, andto obtain building data in meaningful engineer-ing units. However, in the case of Soda Hall, weconcluded that interfacing to the control proces-sors would be the most expedient solution, dueto ongoing system con�guration changes to theEMCS host processor.A gateway testbed facility has been created whichincludes a small version of the EMCS system.This testbed permits us to develop and test ourgateway software without a�ecting building op-erations at Soda Hall.Control and SecurityAt present we do not yet support control func-tions, for two reasons:1. lack of a secure CORBA implementation,2. lack of concurrency control in the buildingEMCS.

Remote control of buildings across the Internetexposes the gateway systems to attack from any-where on the Internet. Systems which employprivate communications networks (leased lines)are less exposed to such attacks. Systems whichemploy other public networks (dial-up telephonesystems) have similar security problems.Hence, secure CORBA implementations will berequired. Our primary concern is authenticationand authorization at the gateway machine of re-mote operators/controllers across the Internet.We assume a secure (e.g., physically secure) com-munications channel between the gateway systemand the building EMCS. We are not concernedin this project with intra-EMCS security, e.g., is-sues arising from sharing local area networks withother users.Present commercial CORBA implementationslack both authentication and privacy (i.e., en-cryption) capabilities. OMG has recentlyadopted a draft security services speci�cation,which has yet to be implemented. We know ofat least two projects which are attempting tobuild secure CORBA ORBs based on commer-cially available ORBs (i.e., Iona's Orbix), theSunrise Project at Los Alamos National Labo-ratory, and another project at Sandia NationalLabs in Livermore. We expect to avail ourselvesof a secure CORBA implementation in the sec-ond year of the project. Note that both encryp-tion and public key-based digital signatures forauthentication are commercially available tech-nologies. The issue is primarily one of systemintegration.The other obstacle to supporting control func-tions, concerns concurrency control at the build-ing EMCS, i.e., coordination of multiple op-erators/computers independently attempting tocontrol the same HVAC equipment. Legacy EM-CSs (e.g., our target system) often support eitheronly a single operator control console, or requiremanual intervention for concurrency control. Re-mote operator controls further complicate suchmanual intervention.CONCLUSIONSIn this paper we have described our project toconstruct a remote building monitoring and con-

Draft ACEEE paper - May 14, 1996 - LBL-38827 12trol system, which will employ the CORBA pro-tocol across the Internet for communications.We have discussed related work, tradeo�s be-tween alternative networking/distributed objectprotocols, tradeo�s among various CORBA andDBMS systems, and a number of design issues inconstructing such systems.We have also outlined the monitoring applica-tions we plan to support in the �rst year.We believe that this approach will prove to beboth feasible and competitive with other systemsbased on proprietary communications protocols.A secure CORBA implementation will beneeded to support remote control functional-ity. Retro�tting concurrency control mechanismsinto legacy EMCS systems will also be required.The attraction of our approach lies in the ex-tensive availability of commercial software prod-ucts which support distributed computing appli-cations based on the CORBA model and under-lying Internet communications protocols.ACKNOWLEDGEMENTSSta� for the project includes Graham Carter(LBNL) and K. Papamichael (LBNL).Our collaborators include: Kristin Heinemeier(Honeywell), Sarah Shirazi, Romeo Cruz, JamesPatterson (UC Berkeley Facilities Management)Barrington Systems.We would like to thank Hannah Chauvet andJohn McCarthy (both LBNL) for reviewingdrafts of the paper. Vladimir Bezjanac (LBNL)has kept us abreast of developments with the IAIdata model.This work was supported by the O�ce of EnergyResearch, O�ce of Computational and Technol-ogy Sciences, Mathematical, Information, andComputational Sciences Division. of the U.S. De-partment of Energy under Contract DE-AC03-76SF00098. The program manager is Ms. MaryAnn Scott.For further information see the web page:http://www.lbl.gov/ olken/BPA/rbo.html

REFERENCESBarrington. 1989. LanSTAR Model SC-LS-1User's Manual. Barrington Systems, San CarlosCA.Ben-Natan, Ron. 1995. CORBA, A Guideto Common Object Request Broker Architecture,McGraw HillBowman, Mark. 1996. Personal communication.Tinton Falls, New Jersey: Measuring and Moni-toring Services, Inc.Cohen, Yoram. 1995. \SNMP - The SimpleNetwork Management Protocol", URL: http://-www.rad.co.il/networks/1995/snmp/snmp.htmlTel Aviv: RAD Data CommunicationsEIA 1992. Annual Energy Review for 1991.Washington, DC: Energy Information Adminis-tration, U.S. DOE.Electrotek. 1996. \A Practical and CostE�ective Demonstration of E�cient EnergyUsage and Quality Management Using theNational Information Infrastructure" URL:http://www.electrotek.com/doe/default.htmKnoxville, Tenn.: Electrotek Concepts Inc.EUN. 1994. \EUN Product Guides: BuildingAutomation Sys tems." Energy User News Mag-azine. October: 50-51.EUN. 1993. \New R&D Consortium to TestInteroperability of BACNet Products." EnergyUser News Magazine. November, 1,25.Haberl, Je�. 1996. Personal Communication.College Station, Texas: Texas A&M UniversityIAI. 1996. \Industry Alliance for Interoperabil-ity Home Page", Dallas, Texas: Industry Al-liance for Interoperability, URL: http://www.-interoperability.com/Illustra. 1996. \Illustra Corp. Home Page".URL: http://www.illustra.com/ Oakland, Calif.:Illustra CorporationKao, J.Y, and E.T. Pierce. 1983. "Sensor Errors:Their E�ects on Building Energy Consumption."ASHRAE Journal. December: 42-45. Atlanta,GA: American Society of Heating, Refrigerationand Air-Conditioning EngineersClaridge, D., Haberl, J., Liu, M., Houcek, J., andAthar, A. 1994. \Can You Achieve 150% of Pre-

Draft ACEEE paper - May 14, 1996 - LBL-38827 13dicted Retro�t Savings? Is it Time for Recom-missioning?" Proceedings from the ACEEE 1994Summer Study on Energy E�ciency in Build-ings, Vol. 5, Washington D.C.: American Coun-cil for an Energy-E�cient EconomyHeinemeier, K.E., and Akbari, H. 1992. \Pro-posed Guidelines for Using Energy Managementand Control Systems for Performance Monitor-ing." Proceedings from the ACEEE 1992 SummerStudy on Energy E�ciency in Buildings, Vol.3, Washington D.C.: American Council for anEnergy-E�cient EconomyHerzog, P., and LaVine, L. 1992. \Identi�ca-tion and Quanti�cation of the Impact of Im-proper Operation of Midsize Minnesota O�ceBuildings on Energy Use: A Seven Building CaseStudy," Proceedings from the ACEEE 1992 Sum-mer Study on Energy E�ciency in Buildings,Vol. 3, Washington D.C.: American Council foran Energy-E�cient EconomyKissock, K., Wu, X., Sparks, R., Claridge, D.,Mahoney, J., and Haberl, J. 1988. \EMODEL,Version 1.4d.", College Station, Texas: EnergySystems Laboratory, Texas A&M UniversityLake, Craig. 1996a. \Remote (Network) MON-itoring (RMON)", URL: http://www.rpm.com/-whitepaper/rmon.html Ellicott Ciy, Maryland:RPM Associates.Lake, Craig. 1996b. \Simple Network Manage-ment Protocol", URL: http://www.rpm.com/-whitepaper/snmp.html Ellicott Ciy, Maryland:RPM Associates.Mowbray, Thomas J., Zahavi, R. 1995. The Es-sential CORBA, Systems Integration using Dis-tributed Objects, New York: John Wiley & Sons.Orfali, Robert, Harkey, Dan, Edwards, Jeri.1996. The Essential Distributed Object SurvivalGuide, New York: John Wiley & Sons.Ott, Peter, Wheltpton, Brian. 1996. Per-sonal communication. Toronto, Canada: Ryer-son Polytechnic University.Piette, M.A. 1996. \Commissioning Toolsfor Life-Cycle Building Performance Assurance",Proceedings of the Fourth National Conferenceon Building Commissioning, Portland, Oregon:Portland Energy Conservation IncorporatedRose, Marshall T. 1995. The Simple Book, An

Introduction to Internet Management, SecondEdition, Englewood Cli�s, N.J.: Prentice HallRuch, D., and Claridge, D., 1992. \NAC forLinear and Change-Point Building Energy Mod-els." Proceedings of the 1992 ACEEE SummerStudy on Energy-E�ciency in Buildings, Volume3, Washington D.C.: American Council for anEnergy-E�cient EconomyMills, E., Olken, F. Piette, M.A. Sartor, D.,Selkowitz, S., Sherman, M. 1995. \Building Per-formance Assurance: Life-cycle Information Sys-tems", URL: http://eande.lbl.gov/CBS/BPA/-BLISS/BLISS.html Berkeley, Calif.: LawrenceBerkeley Laboratory,OMG. 1996. \Object Management Group HomePage", Framingham, Mass: Object ManagementGroup. URL: http://www.omg.org/Selkowitz, S., Olken, F., Piette, M.A., Sher-man, M. 1995. \Assuring Building Performance:Creating BLISS", Center for Building ScienceNews, No. 7, URL: http://eande.lbl.gov/-CBS/NEWSLETTER/NL7/BLISS.html Berke-ley, Calif: Center for Building Sciences,Tseng, P.C., Stanton-Hoyle, D.R., and Withers,W. 1994. \Use of a Supplemented EMCS in Com-missioning." Proceedings of the ACEEE 1994Summer Study on Energy E�ciency in Build-ings, Washington D.C.: American Council for anEnergy-E�cient Economy,Wonderware. 1996. \Common Questions AboutNetDDE", URL: http://www.wonderware.com/-products/netddeq2.html Irvine, Calif: Wonder-ware, Corp.