SYSTEM DESIGN DOCUMENT


OWLII Project

Advanced Software Engineering

Spring 97

Carnegie Mellon University

Pittsburgh, PA 15213

1.0 Goals and Trade-offs

1.1 Design Goals

Facilities Management systems, such as OWLII, are used to monitor workplaces and similar locations to ensure maximum comfort and productivity for the workers. The primary goal of OWLII is to design a Facilities Management system for Intelligent Workplace (IW) project. Current Facilities Management systems are not built to handle a dynamic environment such as the IW; therefore, OWLII will increase the functionality of existing systems. As this project only spans the time frame of a single college project course, the expectation that a fully functional system would be delivered by the end of the project is unrealistic; therefore, the focus for this stage of the project is to create a prototype of the OWLII system that can be expanded on by future contributors.

There are some over arcing goals to the OWLII system, which are to be implemented in the prototype and continued to the final system. These include:

1.2 Design Priorities

No piece of software is perfect. However, every piece of software has certain goals that should be attempted. Even these various goals, however, cannot all be realized, especially not in one semester. Therefore, it is necessary to prioritize the various design goals for the OWLII project. The prioritization that has been settled on is as follows:








1.2.1 Highest Priority Item

1.2.2 High Priority Items

1.2.3 Medium Priority Items

1.2.4 Low Priority Items

While goals such as readability, user-friendliness and adaptability are priorities for any software project, they are not given above-average treatment by the OWLII development teams.

1.3 Design Trade-offs

When developing a software system, sometimes established design goals can lead to an impasse: a situation will arise where one design goal must be sacrificed in order to achieve another. When problems of this nature present themselves, the system's (or subsystem's) development team must make a trade-off, and decide which goal is more important.

1.3.1 System-Level Design Tradeoffs

Some trade-offs arise at the System level, and are shared by most software projects. For instance, a software project has a defined delivery date, requiring that all functionality be completed by that date. However, sometimes all the required functionality cannot be completed by the specified delivery date. The trade-off in this scenario is between required functionality and required schedule: is the system on-time but not complete, or complete but late? Other trade-offs encountered by the system as a whole are functionality vs. efficiency (the client's requests should be handled completely, but they should also be handled quickly) and specificity vs. generality (the system should run efficiently and according to the user's wishes, but should also be portable to multiple platforms).








1.3.2 Subsystem-Level Design Tradeoffs

Some of the subsystems of OWLII have also come across trade-off situations that are specific to that subsystem's functionality.

The User Interface subsystem, for instance, has discovered that speech input, which is a stated requirement of the product, is not supported by Java, which was specified as the language in which all new code should be written. This problem has been solved by specifying that clients will only be available on systems that have established speech input drivers.

The Control subsystem has discovered that the efficiency guidelines given may conflict with the wishes of the user. For instance, in summer, efficiency guidelines dictate that natural light should be minimized in favor of artificial light to save resources that would be spent on cooling. However, if a user prefers to work in natural light even in the summer, the system should accede to the user's wishes. At the time of this writing, the subsystem has not determined a solution to this problem.

The Facilities Management subsystem has found that MicroStation, the chosen Site Editor package, has more functionality than they need, and although the Simulation subsystem requires some of the extra functionality, the package is complex enough that the Facility Manager's required learning time will be significantly increased if they have to learn MicroStation. At the time of this writing, the subsystem has not determined a solution to this problem.

2.0 System Architecture

2.1 Subsystem Decomposition

The OWLII system is broken down into four separate subsystems:

The subsystems communicate with each other through an implementation of the CORBA software bus. CORBA allows subsystems to access objects from other subsystems and remotely call methods of those objects.

Each of the OWLIIís subsystems is broken down further as follows. UI is divided into Visualization and Multiple Input Devices while SO is divided into Database Management and Notification. Control and Facility Management comprises BO and Simulation and Machine Learning makes up DS.



































2.1.1 USER INTERFACE SUBSYSTEM

Multiple Input

The User Interface Subsystem is responsible for providing the means of communication between the OWLII system and the users of the system. The design is aimed towards the goal of having multiple input such as speech, mouse and keyboard.

Visualization

The visualization system provides either a two dimensional or a three-dimensional interface to the Intelligent Workplace, which runs inside of the user interface subsystem. It receives some model of the current Intelligent Workplace layout, which is stored in the system database in some generic format.

2.1.2 SYSTEM OPERATIONS SUBSYSTEM

Database Management System [DBMS]

The Database Management System provides services for storage and retrieval of any persistent data in the OWLII project. These services are provided through a CORBA interface. This subsystem will behave as a server in most instances. Other subsystems will call the public methods of Database Subsystem and process the returned data.

Notification

The Notification Subsystem provides the service of notifying other subsystems when an event has occurred. The subsystems can create events, subscribe to an event and notify other subsystems when an event has occurred. The Notification Subsystem is always a server to the other subsystems and only calls another subsystem when an event has occurred which that subsystem has subscribed to.






2.1.3 BUILDING OPERATIONS SUBSYSTEM

Control [CTL]

One of the two main purposes of the Control Subsystem is to read data from the sensors, and to pass the information received from the sensors to the database. The other activity of the Control Subsystem is to provide an interface for LUXMATE, the shades and light manipulation devices. Extensibility for temperature control and other sensors is included in the design models so it can be added in the future.

Facility Management [FM]

The Facility Management Subsystem [FM] is meant to assist Facility Managers with modifying floor-plans, scheduling room reservations, and maintaining inventory control information. To do this task, the FM will be interacting with UI in a client/server relationship, with the FM being an information provider and providing a CAD tool to allow Facility Managers to modify floor-plans. The FM will also be interacting with the Database subsystem in a client/server relationship. The Database subsystem will be taking care of all the FMís long term data storage needs. Within the FM there are two major divisions: the reservation facility and the controls for building editing and inventory control. The reservation facility is a facility that provides the ability to schedule reservations in rooms. The controls for building editing and inventory control provide and interface to allow modifications to the building, and since the act of moving items is close to inventory control, it has been decided to group these two into one facility. These two facilities interact based upon the creation and deletion of rooms which allow reservations. A final division is outside the FM proper: a CAD tool interface. This tool is something needed by multiple groups (FM and Simulation) to access the CAD tool. This interface is used by the controls for building editing and inventory control.







2.1.4 DECISION SUPPORT

Simulation

The Simulation Subsystem provides a service through which simulations can be run on a site. Currently design is only for an interface to a pair of existing simulators, however the design is easily expandable to include other simulators as they become available.

Machine Learning

Machine Learning will be implemented in the future.

















2.2 System Layers and Partitions

  1. User Interface

User Interface is layered into three main layers: input from the user, various views, and the CORBA bus. The input from the user can be obtained through the GUI with possible speech capability. The view of the domain can be obtained in following ways: 2-Dimensional view, 3-dimensional view, simulation view, diagnostic view, and the control view. Each of the view interacts with different parts of the system accordingly. The CORBA bus layer takes care of the communication between each subsystems.

The SIM partition represents the view that displays the results of a particular simulation request. The DGN partition represents the functionality that displays specific system diagnostic information on the UI. This would inform the Facility Manager with diagnostic information such as a bulb breaking. The CTL subsystem is used to set system parameters. A typical example of this could be setting the building temperature to a particular value.







2.2.2 System Operations

System Operation is partitioned into two main partitions :

The DBMS can be further layered into the DB server layer and the Persistent Storage Engine (PSE) which makes sure that the data within the DB is persistent.





2.2.3 Building Operations

Building Operation is partitioned into two main partitions :

The Control Subsystem will be designed to be adaptable, in that it could provide support for future Control systems like louvers, temperature control etc. Presently the Control subsystem will support the LUXMATE lighting system.











2.2.4 Decision Support

Decision Support subsystem is partitioned into Simulation and Machine Learning.





3.0 Concurrency Identification

The system needs to be able to handle concurrent requests for information. The user interface needs to be functioning at all times. The system needs to be able to perform multiple simulations, navigation of the virtual Intelligent Workplace, and sample sensor data concurrently. We'd like to have all objects concurrent, but there are problems in such a system. We can't have concurrent changes to data in the database or the system loses integrity. Control must be able to be handle multiple requests simultaneously. Concurrency leads to harder coding and the improvements in speed must be weighed against the added complexity to the system.

There are many threads running at once. One thread is the one that user interface subsystem uses to communicate between the user and rest of the system. Control will have one thread for each hardware control system. Simulation will have one thread for each simulation. Facility management will have one thread for its subsystems as well.

The system must provide access to multiple users as well. It needs to be able to handle users doing all of the different tasks from the Intelligent Workplace and other accessible sites at the same time. Since OWLII is a multifunctional, cross-platform system, it's design needs to reflect the implicit requirement of a distributed system, mainly, concurrency.

The subsystems should be able to handle all kinds of queries together in parallel. The simulation and database subsystems in particular must do this. There are problems with this kind of design: we must keep track of which request goes to which user, we must maintain the integrity of the system, and we must avoid deadlock at all costs. Deadlock occurs when the threads are all waiting for each other to complete a request and none of them will ever return.

The concurrency of the system is addressed by several techniques including: distributing copies, and spawning threads with notification. In distributing copies of the code we can have the code run locally on a user's machine which can be concurrent with other users using a copy of the same code on their machine. When we spawn threads we can have concurrent processes running on the same processor. We need to synchronize these threads and communication between them is done with notification and callbacks.

4.0 Hardware/Software Allocation

One of the main design goals of the Object-oriented Workplace Laboratory - OWL II project is platform-independence. Thus, most subsystems have a few specific hardware or software dependencies.

4.1 System Performance

  1. General System Performance

The system response time should be better than the time required by the user to physically go over and turn on/off a control or switch.

The transaction rate handled by the Database subsystem would a major factor that would influence the system performance. The most significant traffic of transactions to the database would occur when the building layout needs to be read. The major parameters that influence the transaction rate would be the number of simultaneous users that are permitted.

4.1.2 Input/Output Performance

The data generation rate can be supported by the current hardware, however the speech recognition input devices could possibly put a strain on the network throughput.

  1. Processor Allocation

There are no specific hardware requirements for the proposed subsystems of the OWL project.

  1. Memory Allocation

The database server will require a minimum of 64MB RAM. A machine running types of simulations could require large amounts of RAM as well, for storing large models and other simulation data.

  1. Connectivity

Orbix was built to be a lightweight product. A null remote invocation takes 0.2 milliseconds. This is the only overhead that a programmer has on a full round trip invocation to a remote object. This demonstrates that Orbix adds very little overhead; most of the cost comes from the underlying communications.

5.0 Data Management

As with many systems, the OWLII system generates and handles a significant amount of persistent data. Persistent data is any data which maintains its state across system reboot. This includes sensor data which is kept around in some form for months if not years. Other persistent data includes space reservation schedules and building layout data. In addition, the OWLII system builds a number of volatile and temporary data stores. For example, the simulation subsystem will keep a local copy of building data for running simulations and UI may generate a VRML model of the Intelligent Workplace on their server. A final category of data can be characterized as semi-persistent data. This is data which is persistent in nature but not guaranteed as such. An example of this type of data is the VRML model generated by the UI subsystem. This model will be stored in files on that team's server until the model changes or the files are deleted. The lack of guarantee of persistence comes from the fact that those models are automatically regenerated when necessary, therefore they do not need to be explicitly saved or archived except for efficiency reasons (i.e. they should only be regenerated when the floor layout of the IW changes)

The OWLII system will use the Common Object Request Broker Architecture (CORBA) to allow subsystems to share global data. This data will be distributed amongst the subsystems. CORBA provides a general infrastructure for identifying and sharing this global data while providing location transparency. This allows communication between any producer and any consumer of data as opposed to a strict hierarchical structure. Persistent data will reside in the Database Subsystem while copies will be delivered upon request to other subsystems. All other data will be handled independent of the Database Subsystem. Each subsystem handles private data and copies of persistent data in a manner which is most appropriate for that subsystem. In the most common case, this data will be stored in main memory, while some subsystems will generate files on their local machine.

Since CORBA allows a clean architecture for distributed data and data processing, the total system will be extensible for future enhancements. Specifically, CORBA allows clean modularity of subsystems such that a new data type required by UI may only require modifications to Database or User Interface. If Building Operations does not handle that data type, then that subsystem will not need to change.

6.0 Global Resource Handling

This section identifies global resources and determines mechanisms for controlling access to them.

The OWL II system uses CORBA to provide communication between the individual subsystems. A general CORBA server will be implemented to deal with subsystem registration and tracking. The tracking will let every subsystem know which other subsystems are active and available for method calls. The mechanism used for this purpose is the Object Request Broker (ORB).

Note: There are several scenarios where the entire system will not be able to operate, even if not all the subsystems are not active/are not running (i.e. down). One such case is when the System Operations subsystem is down. This implies that the entire system can not function since every other subsystem is dependent upon the SO subsystem. Another such case is when the User Interface system is down. Even if all the other subsystems are running no one would be able to access them therefore the entire system can be assumed to be down. Each of the other subsystems may be down at any given point and not affect the entire system. However if the Building Operations subsystem is down then the sensor data will be lost and the IW will not be able to update itself so far as lights, heat, and humidity are concerned. Therefore the BO subsystem should always be running.

7.0 Software Control Implementation

7.1 External control flow (between subsystems)

Objects with blocking methods will be used to handle the control flow between subsystems. Each subsystem will have several methods associated with it. When an action needs to be performed, an object is instantiated and the appropriate method is called. This method would block until the action was completed. In many cases a thread would be spawned for this method call to maintain the concurrency of the system. For actions that may take a long time to complete (e.g. simulations) the method may return immediately and the calling object could be notified through an event service. This method of control flow lends itself to using CORBA and the event service provided by CORBA.

7.2 Concurrent control

All of the subsystems should be able to run concurrently. For example, a user should be able to run a simulation, get data from the database, and raise the light level all at the same time. This is possible because the system is multi-threaded and distributed across several servers using CORBA. Threads allow the user to do multiple activities. Each time the user requests a certain action to be performed, the UI spawns a thread to handle that request. Once the thread is spawned the user is free to request other actions even before the first one is completed.

7.3 Internal control (within a single process)

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, as these details are abstracted away by the software bus. Nonetheless, this is the internal control for each subsystem:

The User Interface uses event driven process control. Additionally, 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 speech and mouse/keyboard. Finally, there will also be a thread to handle the communication with the notification system found in System Operations subsystem.

The System Operation's Database system consists of one (possibly distributed) relation database. Separate threads will handle each incoming request to the database from other subsystems. The Database subsystem will, of course, also have a thread for communicating with the notification system. The System Operation's Control subsystem uses a combination of polling and event handling for process control. The subsystem is decomposed essentially into two layers. In each zone resides a computer which handles all the sensors and actuators for that zone. Each of these computers will have one thread that determines occupancy, one thread which polls sensors data, one thread that actuates motors, and one thread that calculates settings for controls based on by negotiating the various requests users have made to change the settings. The layer above these computers is a single server. The server has one thread for communicating with each of the computers in each zone, one thread for handling communication with the database, and one thread for interacting with the notification object/system.

7.4 User Interface

The OWL II subsystems will not have their own User Interface, instead they will interact with the user through the interface provided by the UI subsystem.

8.0 Boundary Conditions

8.1 Initialization

The first step in the initialization of the OWLII system is the initialization of the CORBA server. Once the CORBA server is made available, each subsystem can start up independently in the following order: System Operations, Building Operations and Decision Support, and then User Interface. This involves initializing its internal data structures and any additional resources which it may need. Additionally, each subsystem must initialize its interface objects. Each subsystem will then register its services with the CORBA server.

In addition to the above procedure, some of the subsystems must perform additional tasks. When a user starts up a User Interface, it must determine which systems are registered and sets up the interface accordingly. Before the Control subsystems is made available, the current environment of the IW is controlled by manual override settings. During initialization, the Building Operations subsystem must obtain sensor readings and slowly transform these manual override settings into those which are properly computed by the subsystem. With respect to the initialization of the System Operations subsystem, a database administrator must be involved in making certain decisions such as whether or not there are any data inconsistencies, and what must be done in such a case.

Once a subsystem is registered with the registry, all other subsystems may invoke its services. On the other hand, 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.

8.2 Termination

The OWLII System consists of several subsystems. Due to careful system design, the interactions between these subsystems have been kept to a carefully controlled minimum. The termination process will be initiated through the User Interface. Once started, the system will terminate in the following order: Decision Support and Building Operations, System Operations, and then the User Interface.

When any given subsystem terminates, it removes all public services from the Registry. Once the entries have been removed, the subsystem is then free to perform any subsystem specific termination procedures that it requires. This may include, but is not limited to, freeing of memory, de-allocating network resources, and releasing any mutual exclusion locks that components of the subsystem may be holding.

Currently, all verification regarding service availability will be handled by exceptions thrown by the ORB. CORBA gives the ORB the responsibility of checking for the existence of a server that can satisfy a given request. If a server is not running, then it initiates a server to fulfill the request. If the ORB is unable to complete this in a timely manner then it can throw an exception to notify the client that the request cannot be fulfilled.

The use of this registry system will result in certain performance degradation, but as it is already provided by CORBA, we have decided that it is expedient to use these services rather than creating new ones from scratch. If the performance penalty proves to be too severe, then it may prove necessary to add another layer which will in effect cache the test for existence of services. However, at this time it is not clear what effects our current model will have on performance.

8.3 Failure

The OWLII system 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.

The main system consists of the CORBA server, user interface, system operations, building operations, and decision support subsystem. Each time a subsystem accesses another subsystem, the request is handled by the CORBA server. If the server is unable to access the subsystem, it will pass an exception to the calling system.

A failure in the simulation, visualization, or facilities management subsystems will not bring down OWLII. If any of these subsystems fails, its services will be unavailable, but the OWLII system can remain operational and stable. However, if the User Interface subsystem fails, the entire OWLII system cannot be accessed. In this case, a browser error notifies the user that the User Interface is not accessible, and the user will not be able to interact with OWLII. Manual overrides, such as switches for the overhead lights, and possibly temperature controls, will give the IW occupants some control of the building until the User Interface subsystem is back up. These overrides will also be used in the event of a failure of the control system.

If Database fails, the User Interface will notify the user of this condition, and the other systems will offer limited or no functionality. Visualization, simulation, and facilities management will not be able to offer any services. Control will still have the ability to control the building environment, but will not be able to store sensor data. The control subsystem may cache some data locally, so that it can be archived when the database is restored. However, if the database is down for an extended length of time, it may be necessary to discard old sensor data in the interest of disk space.

In the event that the CORBA server itself fails, no subsystem will be able to communicate with any other subsystem until the problem is corrected. Each subsystem will detect the failure by a time-out on its access to the ORB. Once the ORB is restored, services must be manually reregistered by a system operator in order to restore the functionality of OWLII.

To restore service after a subsystem crash, the User Interface, System Operation, Building Operations, and Decision Support systems will follow their initialization procedures. The Control system must obtain sensor readings and slowly transform the manual override settings into the proper, computed ones. The Database must be checked to ensure consistency of the stored data. All systems must reregister with the CORBA registry.

In this way, 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.







This page is hosted by the Chair for Applied Software Engineering of the Technische Universität München.
Imprint (Impressum)