Turning Light Bulbs into Objects Bernd Bruegge1, Truman Fenton2, Tae Wook Kim3, Ricardo Pravia4, Aseem Sharma5 School of Computer Science Benedict Fernandes6 Information Networking Institute Seongju Chang7, Volker Hartkopf8 School of Architecture Carnegie Mellon University Pittsburgh, PA 15213
Abstract 40% of the United States' energy is used for heating, cooling, ventilating, and lighting buildings. Given the efficacy of current lighting systems of about 2-6% when measured from the power plant, we are wasting a lot of energy. In this context, the goal of the OWL (Object-oriented Workplace Laboratory) system is to provide a testbed that supports the operation of buildings with more efficient lighting systems. OWL's software architecture is based on a framework using a combination of web and object technology. It offers location-transparent and manufacturer-independent access to a variety of lighting systems. The OWL system supports a user-driven lighting control scheme for the Intelligent Workplace at Carnegie Mellon University. Both on-line remote control and diagnosis of lighting systems are facilitated by the system. With OWL, a lighting fixture failure triggers a "push" type notification event and sends it to a process for further diagnosis and treatment. This paper describes the requirements, design decisions, and the implementation specific experience in the OWL system development. We discuss the "legacy" system interface, the extendable system design using design patterns, and a component-based multi-modal user interface with Java Beans technology.
1.0 Introduction In buildings, lighting, heating and cooling requirements are directly interrelated. In commercial
1
[email protected] [email protected] 3
[email protected] 4
[email protected] 5
[email protected] 6
[email protected] 7
[email protected] 8
[email protected] 2
buildings, all lighting energy eventually becomes heat energy and must therefore be cooled away, adding additional energy requirements. About 35% of all electric energy in U.S. is used in office buildings and the majority of the electricity is used for lighting. Health, well-being, motivation and productivity of office workers (over half of the US workforce of 120 million people) depend significantly on the appropriate quantity and quality of lighting, including daylight systems. Glare (reflected or indirect), illuminance and contrast values are critical.
Figure 1: Interior View of the Intelligent Workplace
The OWL system is an attempt to deal with these challenges. OWL offers opportunities for remote control and diagnosis of the lighting systems in the office environment. OWL facilitates new building control approaches which require user controls over
the environmental factors in response to the personal needs of occupants [ABSIC/CERL 1995]. From their user interfaces, occupants may request changes in temperature, light level, and the other aspects of the environment. These changes are then effected through adjustments in exterior louvers, internal lighting systems, and the HVAC system. Through a network of environmental sensors located in each work area, an energy efficient adjustment of building climate systems can be formulated and executed. OWL is a typical distributed system dealing with the complexity resulting from the size of the problem-domain being modeled, as well as the number of subsystems required. Distributed object technology, deployed in OWL, showed a potential to cope with those challenges. Two major issues such as component integration and legacy system integration were identified. Component integration was an important issue because not only multiple vendor-specific control servers, but the user interfaces are to distributed. Legacy system integration needed special attention mainly due to the requirements to interface to the Luxmate server, a lighting control system provided from Zumtobel Inc., Austria. The following sections will show how the system requirements were formulated and how those requirements have been handled in the development of the OWL system.
2.0. OWL System Requirements The following set of typical use cases guided the design of the OWL system. Use Case 1: Monitoring. A Facility Manager browses real-time sensor values on the screen and navigates through the building components and systems to get more information for building operation. Use Case 2: Control. An Office Worker launches the on-line control interface, selects the lighting fixture, turns it on and dims it up or down by clicking buttons. Depending on the chosen user action, the lighting fixture adjusts its luminous intensity to maintain the desired state. Use Case 3: Diagnosis. A Facility Manager gets a "push" type notification from the system informing him of a luminaire failure. After a Maintenance Technician replaces or fixes the luminaire, the Facility Manager gets a "back to normal" notification from the system. Use Case 4: Zoning. A Facility Manager logs on the system, ungroups or regroups a set of luminaires to be controlled collectively using visual components displayed on the site or the building plan. The functional requirements of the OWL system are:
1) Individualized on-line control of the luminaires, the blinds, and the HVAC 2) "Push" type notification of building system failures through visual alert with necessary information displays 3) Operation and diagnosis of multiple facilities from a remote location 4) Dynamic re-configuration of control zones 5) Visualization of crucial information including sensor values, system control settings, lighting zones, and error conditions 6) Navigation through a site at varying levels of detail, where site is defined as a set of one or more buildings The following lists the non-functional requirements of the OWL system. 1) Simplicity of User Interface: Turning on the lights of an office with OWL should be as simple as using the light switch in that room. 2) Vendor-Independent Support: Flexible and modular support for hardware from many vendors with various degrees of computer interactions is required. 3) Location Transparency: In order to facilitate portability and ease of use, the actual locations of the OWL servers should be transparent to the clients. 4) Fault Tolerance: The system should be resilient to individual server and client failures. 5) Ease of Use and Learning: The system should be relatively self-explanatory and intuitive to use. 6) Response-Time: OWL should perform as well or better than the manual controls or sensors. Users should experience a reasonable response time from OWL. 7) Portability: OWL's clients and user interface should be easily portable to a new platform. 8) Reuse of Components: The individual subsystem of OWL should be easily extractable and applicable to other systems if similar functionality is required [FERNANDES 97].
3.0. OWL System Design 3.1. OWL's Software Architecture OWL's software architecture was designed as a collection of subsystems communicating over an object bus as shown in Figure2. The User Interface (UI) is responsible for providing ways of communication between the OWL system and its users. Its design supports multi-modal inputs such as mouse, keyboard, speech and even gestures in the future.
SYST EM OPERAT IONS
NAM E SERVICE
DATABASE
BUILDING OPERAT IONS
CONTROL SERVER
NOTIFICATION
DECISION SUPPORT
SIM ULATION
FACILITY M ANAGEM ENT
M ACHINE LEARNING
DIAGNOSTICS
OBJECT BUS
2-D VIEW
SUBSYSTEM VIEWS
USER INTERFACE
the Luxmate server, we explored JNI/C++ and CORBA (VisiBroker for Java 2.5 on the client side, VisiBroker for C++ 1.5 on the server side). For the location-independent access to OWL, we set up the OWL Web Server using the Java web server tool. Versant and POET were attempted to implement the Database subsystem, but we ended up writing our own DBMS based on the ODMG specification. JDK 1.1.1's non-backward compatibility with JDK 1.0.2. introduced an integration problem with some older OWL code written in JDK 1.0.2. We solved this problem by channeling socket level communications between JDK 1.1.1 and 1.0.2. Figure 3 shows the software and hardware mapping in OWL system.
Figure 2: OWL System Software Architecture R S-232 Proprietary Protocol
Building Operations is composed of the Control subsystem and the Facility Management subsystem. The Control subsystem reads data from the sensors and provides a generic manufacturer-independent interface to the specific control system. The Facility Management subsystem supports users to manage the building. System Operations covers the Notification, the Database, and the Naming subsystem. The Notification subsystem provides an event service based on the OMG's Common Object Service Specification [COSS 97] for subscribers and notifiers of the events. The Database subsystem provides services for storage and retrieval of any persistent data in the OWL system. The Naming service provides a registry, which allows OWL servers to be moved from one host to another, or to be dynamically started up anywhere on the network with a basic form of load-balancing and high availability. The Decision Support covers the Diagnostic, the Machine Learning, and the Simulation subsystem to help OWL to make intelligent decisions based on a variety of parameters and models. The Diagnostics subsystem provides error-detection and notification mechanism for the building systems. The Machine Learning subsystem will use sensor data and learning algorithms - such as neural network, to enable the OWL system making intelligent and pro-active decisions. The Simulation subsystem will provide model-based predictions on the potential interactions between the environment and the building systems controlled by OWL.
3.2. Software and Hardware Mapping JDK1.1.1 was used for the implementation of the OWL system. The User Interface is based on Java Beans. The object bus in OWL was mostly realized in RMI. Luxmate server's 16-bit Dynamic Link Library, written in Microsoft Visual C++, required the Luxmate system to run on a Windows machine. To interface to
JDK 1.1.1
x86,W 95, JDK 1.1.1, VC ++ VisiBroker for Jav a/C ++
Database S erv er
Notification Server Diagnostics S erv er
Luxmate Serv er(VC ++) C ontrol Serv er
[electra.se.cs.cmu.edu]
[ aeg.se.cs.cmu.edu ]
[decaf.se.cs.cmu.edu]
JDK 1.1.1
LUXM ATE LEG AC Y LIG HT SY S TEM
O W L S E LAN
H TTP R E Q U EST/R ESPO NSE
JDK 1.1.1
IN TER NET / IN TR AN ET
OW L W EB S ER VE R
[cascade.se.cs.cmu.edu]
Figure 3: Software and Hardware Mapping in OWL
3.3. Control Subsystem Figure 4 demonstrates how control action gets to the terminal device and vice versa. The Control Bean represents all the controllable objects like lights and provides methods for drawing and contacting its peers on the server side. The peers on the Control Server side contact implementation specific objects which actually interact with the legacy system.. The Luxmate Wrapper has a switch which instantiates either the JNI Luxmate Wrapper or the CORBA Luxmate Wrapper. Through either of these wrappers, one can instantiate any service provided on the Luxmate Server which eventually gets to the Luxmate specific hardware such as a luminaire or a blind. Figure 5 shows a part of the Control subsystem object model. The ControlBean and the ControlServer communicate via RMI. The ControlServer talks to the ControlComponent which is the superclass of all controllable objects. The LightControlComponent, a subclass of the ControlComponent, forms a composite pattern with its associated classes. With the same pattern, the BlindControlComponent also inherits from the
ControlComponent. All ControlComponents use a ControllerInterface object. CONTROL B E AN [aeg .se.cs.cm u .ed u ]
RMI
CONTROL S E RV E R CORBA LUXM ATE W R AP P E R
IIOP
CORBA S E RV E R
sockets
L eg acy L u xm ate S erver
LUXM ATE W R AP P E R JN I LUXM ATE W R AP P E R
JNI
N AT IVE IM P L E M E T A T IO N
sockets
RS232
[d ecaf.se.cs.cm u .ed u ]
L U X M A T E L IG H T SYSTEM
Figure 4: Detailed View of the Control Subsystem
To provide vendor independence, the ControlComponent object delegates most of the calls to a ControllerInterface object. The Controller such as the LuxmateLightController or the BlindController implements the functionality of controlling objects dependent on the vendor. There also is a set of classes for sensor controllers which depends on a "peer" objects. These classes cannot be instantiated without an OwlObject (the LuxmateLight for Lights and the LuxmateSensor for Sensors). Thus, the implementation of the LightControllerInterface is done by the LuxmateLightController. These objects are all remote. The LuxmateLightControllerImpl uses a singleton class called the LuxmateWrapper which is the actual connection to the native code. The LuxmateWrapper also has methods for blinds and this is how the blinds should operate as well. The Control Bean maintains independence because it only knows of a light object that could contact the Control Server's vendor independent LightController object implementation. C ontrolS erver
C ontrolB ean
O wlO bject
The Diagnostic subsystem notifies the instance of a lighting system failure as well as its recovery to the User Interface. In our the JNI interface to the Luxmate system, the native part of the LuxmateWrapper communicates via TCP/IP with Zumbtobel's Luxmate server. When an event occurs at the controlled system level, the hardware notifies Zumtobel's Luxmate server which then sends a message to the native part of the Luxmate Wrapper via TCP/IP. Normally, this should start a thread of execution that would reach the pertinent handling functions which eventually call Java code. In the Windows environment, the Windows OS does not asynchronously start a thread of execution for "messages". Instead, some other object has to call the GetMessage( ) and the DispatchMessage( ) function, consecutively. The DispatchMessage() function is responsible for making sure the message gets handled by whoever is registered to "listen" to those types of messages. This is normally done indirectly, for example, when an object asks to "listen" to a socket, it eventually registers the pertinent function. All Windows messages go to the same "message pump" and to get those messages one essentially has to poll the message pump. Normally, when one creates applications with Visual C++ or with the MFC framework, this complexity is hidden from the developer. Initially the messages received from the socket were never handled until a call was issued to send a message through the socket. This problem was solved in our CORBA-based interface for the Luxmate system. To enable failure signal propagation, the Diagnostics subsystem is integrated with the Notification and the Control subsystems. The Diagnostics Bean is integrated with the Notification and the UI subsystems. The Diagnostics subsystem simply expects that some agent will post light bulb failures onto a notification channel. When the Diagnostics subsystem sees such an event on the notification channel, it updates it's User Interface which then notifies the user, for example by turning the color of the light bulb icon from green to red.
3.5. User Interface Subsystem
C ontrolC om ponent C ontrollerInterface LightControlCom ponent
3.4. Diagnostic Subsystem
Light
S ensor
B lindC ontrolC om ponent C ontrollerableO bject LightController
Luxm ateLightC ontrollerIm pl
S ensorC ontroller
Luxm ateS ensorC ontrollerIm pl
Luxm ateW rapper
Figure 5: Object Model of the Control Subsystem
The most important criteria for OWL's User Interface(UI)were reusability and extensibility, which motivated us to select a component-based object technology implemented in Java Beans. The GUI Bean in OWL contains a 2-D view Bean, 3-D view Bean, Menu Bean, Control view Bean, Diagnostics view Bean, Keymap view Bean, and a Text Area Bean. Interaction between the Beans is established through the events handled by the adapter classes. For example,
the event switching from a 2-D view to a 3-D view would be notified by the Menu Bean to all the listeners, the 2-D view Bean, the 3-D view Bean and the UI container itself. The UI container eventually hides the 2-D view and displays a 3-D view. To "listen" to an event, a Bean should register itself to the event coming from the source Bean. Through the pertinent adapter classes, the Menu Bean can be connected to either the 2-D view Bean or to the 3-D view Bean. Each of the Beans "held" by the GUI Bean, can also act as a container. The container does not know how or what a Bean will "look" like once it is displayed. To change the way a UI looks or acts, one only needs to "swap" the old Bean with a new one, and update the adapter objects accordingly. The solution to differing input methods is already built into the Java Beans technology. A Bean is interested only in the events that are fired, not how the event was triggered. This implies a user can use a mouse, keyboard shortcut keys, or even voice (if a speech recognition system is installed) to select the 3-D view menu item. The adapter object for each input device Bean connects the Menu Bean with the particular input device Bean. Once the Menu Bean fires the event, the 2-D and the 3D view Beans respond. When the user clicks on the KeyMap Bean, a Move-to event is sent by the KeyMap Bean to the 2-D or the 3-D Bean. Those Beans then know that the user is interested in viewing a particular region on the KeyMap that the user clicked on. Also as the user clicks on controllable objects in the 2-D view, messages are fired to the Control Bean which knows how to display the controls of the object clicked on. As the controls on the Control Bean are changed followed by the hardware response to it, the Control Bean fires events to the listeners( the 2-D or the 3-D or a switchon. Bean) to reflect the change such as a light switchoff.
3.6. Database Subsystem The support for JDK 1.1. compiled classes and transparent and implicit persistence were important DBMS selection criteria for OWL. We also wanted a package which offered client-side access to server-side objects to alleviate the burden for maintaining the coherency of the data. Both POET and Versant claimed support for JDK 1.1. transparent/implicit persistence and offered client-server functionality. But we realized that the combination of JDK 1.1. and transparency would not be supported by Versant until late into the project. POET's tight Java bindings also revealed some implementation problems. Our class names such as edu.cmu.owl.fm.LightingFixture and edu.cmu.owl.fm.Lighting were too long and not unique in the first 11 characters. We attempted several fixes including the use of POET aliases, but to no avail. The
final design was one which resembled the ODMG bindings, yet offered little functionality. We handcoded a simple server which could create new objects, perform simple searches on those objects and store those objects into a flat file by object serialization. A persistent object was defined as a subclass of the java.rmi.UnicastRemoteObject, thus each was accessible via Java RMI references and remote calls. We provided absolute consistency at the expense of performance. On the positive side, since our server provided bindings similar to those specified in the ODMG specification, only minor modifications would be necessary to integrate the project with a commercial ODBMS which provides the ODMG bindings.
4.0. OWL System Design Rationale 4.1. Object Bus Selection: RMI vs. CORBA The object bus in OWL serves as the communication infrastructure that supports peer-to-peer computing. We considered two candidate object buses: CORBA from the OMG and RMI from JavaSoft. RMI offers the ability to optimize performance through the use of "smart proxies" and to interface with legacy systems using native methods. It surpasses CORBA by allowing complete flexibility in the design and the implementation of the remote interfaces as well as the transferable objects. Specifically, CORBA does not allow polymorphism on remote interfaces and the encapsulation or constrained behavior on IDL structs. Furthermore, the Java to CORBA bindings in an initial OWL version had some latent errors due to the way that IDL sequences are constructed and handled. RMI fulfilled the major design goal of easy portability to a large variety of platforms. JDK 1.1.1ís Object Serialization allows entire object trees to be passed from server to client or vice versa. RMI provided Distributed Object Services such as naming service, security services, and asynchronous event notification services [FERNANDES 97].
4.2. Integrating Legacy Systems: Insights The JNI approach to legacy application integration was more complex than the CORBA approach. For example, we encountered many problems in integrating JNI with Visual C++ DLL's, which were built for the Luxmate legacy system. The CORBAbased approach provided a more robust solution in terms of event notification. In this approach, the listener applications received all the events generated. The JNI-based approach is better suited to a client/server architecture, where clients invoke methods on servers and wait synchronously for a reply.
In terms of development cost, the JNI-based approach was harder to implement. The JNI protocol requires that a dynamic link library be built out of all the native method implementations. The parameter passing techniques and notations used in translating between Java and C++ and C++ and Java are non-trivial. The CORBA solution provides a cleaner separation between the CORBA and the C++ code. Because it is packaged into a single process, the JNI-based solution was faster than the CORBA solution. The client-server handshaking takes place over the Naming service, which is indeed very helpful in a truly distributed environment, although it adds overhead [FERNANDES 97]. Figure 6 shows the structure of the CORBA based interface to the Luxmate system. JAVA-based Front End
(Sockets) CORBA
LEGACY SYSTEM
CLIENT
CORBA Luxmate wrapper (Java/ CORBA)
CORBA Native Implementation (C++)
LEGACY APPLICATION
Proprietary Protocol
LEGACY HARW ARE
Figure 6: CORBA-based Luxmate System Interface
5.0. Conclusions The OWL system development presented many challenges due to the choice of the application domain and the software engineering techniques used during the design phase. The combination of design patterns and the component technology dealt with these challenges and led to a flexible and modular system architecture. We witnessed rapidly changing technology in the software development community during the 6 months project period. The combined use of Java - for writing new applications - and CORBA for interfacing to the legacy system - was a success despite the problems encountered by using experimental technologies. We found that competing technologies such as CORBA and RMI have their particular niche areas of applicability providing complimentary technological solutions in a large software architecture such as OWL. We now envision an OWL system which grows by adding more subsystems offering opportunities for remote control, diagnostics, and facility management, anywhere on the globe.
6.0. References [ABSIC/CERL 1995] ABSIC, USACERL, Flexible Grid - Flexible Density - Flexible Closure Officing: The Intelligent WorkPlace, USACERL Contract DACA88-93-0004-Phase 1, 1995 [BOOCH 97] Booch, Grady, Object-Oriented Analysis and Design with Applications, 2nd Edition, The Benjamin/Cummings Publishing, 1997. [CURTIS 97] Curtis, Jim, CORBA versus RMI, OMG Whitepaper 1997 [FEGHHI 97] Feghhi, Jalal, Web Developer's Guide to Java Beans, 1997 [FERNANDES 97] Fernandes, Benedict, An Experimental Evaluation of A Component-Based Distributed Application: The OWL System, Master's Thesis, Carnegie Mellon University, 1997 [MORAN 97] Moran, Thomas and John Carroll, Design Rationale - Concepts, Techniques and Use, 1997. [ORFALI 97] Orfali, Robert and Dan Harkey, Client/Server Programming with Java and CORBA, John Wiley, 1997. [COSS 97] CORBA Services: Common Object Services Specification, OMG, Revised July 1997 [RUMBAUGH 97] Rumbaugh, James et.al, ObjectOriented Modeling and Design, Prentice Hall, 1997.
