This document addresses the object design of the OWLII system. OWLII system intends to provide a distributed software environment for remote building lighting system operation & management accessible on the Internet. The intended audiences for this document are the system developers and the clients of the project.

Client, System Designer & Developer

The OWLII project is for developing a distributed lighting control support system serving to the Intelligent Workplace at Carnegie Mellon University. The OWLII system aimed at supporting building operation tasks especially the control and diagnostics of lighting systems using internet-based object technology. The basic motivation of this project is to provide a healthy and productive way of managing and controlling built environment while allowing energy effective and sustainable additions to it.

The systems integration based on the advanced building technologies is a promising movement in building industry. This is especially for maximizing occupant comfort and productivity while maintaining cost-effectiveness as a whole. On the other hand, the emerging paradigm of the internet and object technology based information systems is becoming more and more advantageous prototype in current software development efforts. OWLII tries to integrate and to demonstrate those promising software technologies to support various building operation tasks such as remote monitoring, control, and management of building systems. This global vision will be pilot-tested in OWLII through realizing software-based and user-driven lighting system control scheme. The outcome of this project will allow users to be able to monitor and control their micro-environment in the office. The potential power of virtual reality as the new generation user interface types were attempted in this project. Location and platform independent access to the system services was another target of OWLII system development. Eventually, establishing a robust generic system architecture for cross-domain applications will be explored with OWLII project. This will allow future extendibility of OWLII system architecture to support other domain problems such as mobile maintenance of various vehicles.

The Intelligent Workplace, as the target building for OWLII project, has completed structural framework and envelopes. Light redirection louvers and some sample lighting fixtures were installed. The dynamic changes of illumination level inside the building have been recorded by the sensors developed by the team of researchers at Machine Learning laboratory, Carnegie Mellon University. The control infrastructure for the entire building was designed but not delivered, yet. Johnson Control’s Metasis and Siemens’s Instabus control systems will be delivered soon. PEM(Personal Environment Module) and HVAC(Heating Ventilation & Air conditioning) system have not been installed, yet. The building itself is not operational as of the creation of this Requirements Analysis Document. Luxmate system as the major legacy system to be interfaced by OWLII system is developed by Zumtobel Inc. in Austria and has a complete set of hardware and software for infrared or computer-based control over the various daylight and artificial light states. Luxmate’s user interface runs only on Win32 environment and bringing it on the internet to make it available on any platform at any location is one of the challenges in OWLII. SEMPER as the integrated building simulation environment is under development at Center for Building Performance & Diagnostics, Carnegie Mellon University. Microstation as an CAD(Computer Aided Design) environment is now developing JAVA-based API(Application Programming Interface). The progress of those system developments are crucial for long-term OWL project implementation.

Proposed OWLII system is to make a location and platform independent building operation support system for the Intelligent Workplace. Remote building monitoring and control through the interactions with 2 dimensional or 3 dimensional building displays on the internet will be the most important functional aspect of this project. The possibility of location and platform independent user control over his/her work environment will be demonstrated through interfacing Zumtobel’s Luxmate lighting control system. Lighting fixture break down will be effectively notified and handled by OWLII system until it could be taken care of by facility manager. OWLII will be a totally distributed object-oriented system so that the distributed remote objects could communicate through the network for assisting various user requests. This system architecture will also allow the future expansion of the system. To increase reusability and portability, OWLII will exploits component technology and platform independent programming language such as JAVA. Reuse of OWL system architecture and design will make it possible to extend system applicability to solve other domain problems as well.

In most of current building operation, tracking current state of the building spaces, components, and systems is not easy for the facility managers. Control systems in a building, typically, are either tied to pre-defined system or just reactive to the weather changes regardless of individual occupant's needs. The concept of user-driven control has been introduced to the building operation domain but not successfully implemented yet. Even though the opportunity of being on the web for remote building monitoring and operation exists, it also has not been fully exploited yet. Furthermore, the typical graphic user interface of a stand-alone building control software is usually platform-dependent and does not provide a fully integrated interactions between users and the system. This limitation is critical especially in user-based control scheme. Prediction of potential problems also is not easy task. Decision support systems based on simulation or other AI(Artificial Intelligence) techniques have not been sufficiently integrated for the building control or facility management tasks. Increasing mobility of potential users make it necessary to remotely access dynamically changing information such as sensor values of a specific building operation even when it is necessary.

OWLII is trying to solve those problems described above in the software-based way. As a fully facilitated lighting control system, Zumtobel’s Luxmate system manages light levels automatically or as defined by facility managers and users. OWLII project is aiming at Luxmate control interface available on the internet regardless of the type of platform and the potential users. Eventually, OWL system will use real-time weather data from the internet, occupancy sensors, internal/external light sensors, machine learning and simulation tools for control decision making. Lighting systems such as light louvers, window shades, skylight shades, and perimeter lights will be included as the target systems. OWL system eventually will support manufacturer independent user-based lighting system control. The system also will provide the functionality to place and track properties within the building, to design floor plans, to create a schedule for rooms, to assign people to rooms, and to track problems and malfunctions within the building systems.

With OWLII system, users are supposed to navigate through, visualize, and interact with the Intelligent Workplace. Either a 2D floor plan of the Intelligent Workplace or a navigable 3D model, is to be displayed while allowing interactions between system and users. Web-based VRML model will be built to display Intelligent Workplace in 3D view. By being connected to a CAD system such as Microstation, an authorized user can modify, delete, and create new building components or layout. This mode will allow the client to create new designs for the workplace and to simulate design options in various contexts.

3.2 Functional Requirements

The system should be able to control internal light levels according to user defined settings optimized by the global control strategy. For user-based control, users in the same room will contribute to come up with a consensus light level. Eventually, for optimal global control, simulation and machine learning-based decision support systems will cooperate with controllers. To achieve this goal, external light levels and energy consumption should be taken into account for energy efficient lighting control. The system will also monitor sensor values and will notify malfunctions of lighting devices for the maintenance purpose. An authorized user such as facility manager must be able to update the Intelligent Workplace floor plan to reflect the current or desired physical layout on the database. In this case, user must be able to perform iterative, "what-if" simulations on optional designs to select the most attractive solution out of candidate designs..

For effective human-computer interactions, OWLII system should provide advanced input/output mode especially 3D navigation interface with Intelligent Workplace. This type of browser is to be used to display sensor values and to manipulate light system settings. The ability to navigate through a three dimensional representation of the Intelligent Workplace also has to make it more natural to get the most updated building information for further interaction by activating "hot spots" in it. More detail functional requirements are described in section 3.5.1 Use case Models.

Different types of users should have different access rights when they use OWLII system. Multiple inputs or multi modality is to be considered in user interface design. Within one framework, multiple visual components should be organized in such a way that the user can flexibly execute demanded use cases without being interrupted by various distracting visual events. The user interface should allow future implementation of speech recognition to achieve multi-modality.

3.3.2 Documentation

On-line documentation will be provided for the client, system administrator and the continuous system development team. User manuals for OWLII system usage instructions will be prepared according to the specific user group and the potential usage of the system by them.

User should be able to access to the OWLII system through any available platform capable of running Java and a web browser. Enhanced operations will be available on Sparcs and Macintoshes, as these two platforms are the expected majority in the Intelligent Workplace. If speech recognition is implemented, any user using speech as input mode needs a sound capture device, a high-quality microphone, and appropriate software drivers to support the mechanism used to capture their speech. The display of a machine running the interface should be high resolution and in color. For VRML browsing, either PC or MAC having high computing power and memory are recommanded. CAD tool for building design editing also should be able to concurrently run Netscape and several applets. For lighting control, Zumtobel’s Luxmate system is to be interfaced to OWLII.

The user interface should be able to handle frequent updates while allowing acceptable delays

in information processing. For capturing and interpreting multi-modal inputs such as voice recognition, specific rate of computing power and speed must be considered. The interaction with user interface should not be slower than the conventional way of interaction as is in the case of manually turn on or off the lighting switches in a room. Especially, 3D navigation through VRML browser needs high-performance machines for the dynamic building geometry computations at an acceptable speed. The non-volatile data to be used by the system for the VRML model and Java byte code to support dynamic changes of 3D views. Depending on the complexity of the model selected for VRML representation, this data may several tens of megabytes. Both frame rate and smoothness should be considered especially for the 3D navigation browsing. The Available compute power of host processor and physical memory resources on the VRML server determines those performance characteristics, respectably. The system is supposed to respond to the user interactions in a timely manner.

The database must be able to accept sensor data and control output data at a certain speed. And it must also be able to handle large amount of concurrent reads and writes from multiple clients and servers. Considering CAD related data, the site or building models may be large and the libraries of materials may be quite extensive. Both of these factors require a sufficiently fast network connection. At this time, a 10 megabit/sec network will be sufficient. However, as the size of the model grows, this could not be fast enough. The network should support high bandwidth capabilities for transferring real-time sensor data. The conversion between building object model and the CAD tool's native format could be a long process as the size of the model grows.

If occupancy sensors are to be installed, the system should respond within seconds to changes in occupancy. For example, if somebody walks into a previously unoccupied room, the room should be illuminated with in a few seconds. Latency includes loop process of sensing, transfer of sensed value to the control agent, back signaling to actuators, and execution of control command. This latency should be adjusted by the evaluation on the potential psychological irritation and tolerance over the controlled processes. All the other sensors will be polled at 3-5 minute intervals. After the sensors are polled, the system will update all of the actuator statuses.

3.3.5 Error Handling and Extreme Conditions

The user interface should be designed to avoid possible user input errors such as nonsensical or unauthorized control actions by the user. In case a system module fails, the user interface should continue to work without it. For example, if a fault occurs in a simulation module other system modules are supposed to be continuously functioning unaffected. The user just gets some message like "no output received from simulation module." Prevention of errors is the robust way of dealing with potential system malfunctions. Due to the dependency of CAD module on the building object model, illegal object creation with CAD tool should be dealt with by the preventive error checking mechanism which catches the error, notifies the user that error in the input to have user action about it. The whole system needs to be designed to fail gracefully if extreme conditions arise that prevent its further operation. Additionally, users should be kept well informed of errors, but not in a way that makes the interface difficult to use. Additionally, user should be provided a mechanism to be notified errors from other system modules.

Possible error conditions in 3D navigation browsing include invalid VRML input, inability to communicate with the machine that provides the VRML input, and any problems that occur internally with the VRML browser. Low memory could be the possible extreme condition in 3D navigation.

Any system module requires updating some data should signal the User Interface if there has

been an error in input and request corrected the input. The system will not allow anything to

be changed or updated until the correct input is received or the task is aborted. Database could be malfunctioning when it encounters a lack of disk space and a number of entries close to or exceeding the maximum number of entries the database can handle. when only 30% of the disk space is unused, a warning message should be recorded in the error log. When the available disk space falls below 10%, the database should respond to all incoming storage requests with an indication of data storage failure and signals an alarm for the data storage administrator to free up disk space.

In terms of building system control, some potential errors might be caused by either physical system damages such as bad sensor, bad actuator, crashed computer, defect network or by functional defficiencies such as abnormal control software behavior and network traffic jams. Interrupted, monotonous, or unreasonable sensor reads should be identified by the system to trigger notification process to the facility manager. Actuator malfunctioning should be detected using history data of control signals and sensor values. Extreme conditions, such as outrageous user-specified light levels should be prevented based on automated global control scheme.

User interface should be able to communicate with other system modules directly or indirectly. User Interface could simply request remote objects independent of which system module the access methods operate on. Especially, user interface should be able to interact with the Database module, where the information would be stored as objects so that user interface can use the services of the database to act upon it. User interface would use object bus and should be running on any platform to make it available in a totally distributed environment such as Internet. All domain specific system modules are supposed to communicate at least with User Interface and Database. For example, the control module gets user-specified light level settings from the User Interface, sends sensor readings and hardware position data to Database, and reads the layout of the room, and the room-hardware associations from the Database. Cause most of system modules are to be communicating with the Database, it should provide an interface through which most of input requests from other system modules and their results could be handled efficiently. In this scheme, the interface object to the database is to return the appropriate result to its caller.

The VRML-based 3D navigation acquires data from the Database before generating a VRML representation of chosen scene by the user. It also delivers messages to the User Interface when the user of the VRML model enters a space or actively selects a control object. These messages simply indicate the location of the camera view (the user's "position") or the identity of the control object actively selected by the user via a hotspot.

Legacy system interfacing is an important requirement for this project. Luxmate lighting control system should be integrated for making its service available at any remote place on any platform. Interface between the OWLII system and all the building control hardware including Luxmate system should be taken care of in the way that it could handle multiple group of manufacturer-dependent hardware in a generic way.

The CAD tool such as Microstation also should be integrated to the system so that building geometry inputs or updates could be reflected on the Database and on other system modules as well through User Interface. All interactions with the CAD tool after startup are to be handled by the pertinent system module(s). The lighting simulation system such as SEMPER lighting module is another legacy system to be integrated. It will be receiving its input from both the User Interface and the Database. CAD tool is to facilitate building geometry inputs necessary for the simulation. For specifying certain zone or space of the building, 3D navigation module could be used as a part of User Interface. To make it happen, both CAD tool and 3D navigation module should be effectively integrated into User Interface. For future extension of the system, any simulation module should be able to get input data from the other simulation modules depending on the inter-dependencies between different simulation domains. For simulation, weather data and sensor values are to be processed and saved on the Database based on the properly determined time interval. This output of simulation will then be displayed in a human readable graphical form on the User Interface. To avoid conflicts, any object bus for implementing distributed computing should be able to handle cross-lingual communication between the legacy simulation engines and the system being developed.

Reliability in User Interface and Database is the most important requirement. Even in the event that a system module dies, the User Interface must continue to operate except whatever functionality that specific system module provides. If the system module provides a critical function (e.g. ORB server), the interface will exit gracefully. User should always be able to restart the User Interface in a reasonable amount of time although particular system module may in fact remain down. Restarting of the system or a system module after a failure should be taken care of by both the Database and ORB to make interrupted job persistent. Database must be reliably running during control hours in Intelligent Workplace without maintenance. In control, reliability requirements include server stability and accurate transmission of data. Should the server go down, only changes due to manual override will take place. Memory-intensive system module like 3D navigation server should be failure-free in viewing dynamically updated images. For this reason, the target platform must provide sufficient virtual memory resources to support 3D navigation viewer. 3D navigation browser must be able to catch all exceptions thrown by objects used in developing this supporting code. These exceptions might include but are not limited to insufficient memory, invalid user input, and network failure.

Another system quality issue is portability which measures the ability to move a software to different hardware and operating system environments. For example, the VRML 2.0 specification is platform independent, so any VRML-compliant viewer on any platform should be able to support the 3D navigation. Simulation module also must be portable. One of constraints could be the CAD tool’s platform dependency, which can limit the availability of simulation service on multiple platforms. Using a platform-independent programming language such as Java aids portability except some known problems.

Error handling is the other important system quality issue. With User Interface, errors caused by a user should be trapped and then the user is to be asked to correct the faulty information. System errors should be trapped and logged in a file for later inspection. With errors happened, Database should be recoverable within one hour of failure time to trap control faults under the minimized impacts.

There are three major sources of potential system changes which should be considered during system development. Physical component or system changes in Intelligent Workplace could cause OWL system modification. Modern buildings are to be continuously evolved even after the construction. For instance, if a new solar cell is installed, a new sensor would have to be implemented to monitor electricity generation, and legacy data might be logged in the database to analyze trends. Addition of the new or replaced spaces, new space elements, and new enclosure elements could cause building object model change reflected on Database. Modifications to the relationships between building related objects, although is highly discouraged. It would take considerable time and effort to carry out this type of modification, and as a consequence could make the system unstable. Different lighting control systems other than Zumtobel’s Luxmate could be installed in Intelligent Workplace. This might necessitate software changes, and would be analyzed, designed and implemented by a group of software re-engineers with the customer.

The other source of system modification is change or extension of client requirements on the system. For example, the User Interface would have to be changed if the customer later decides that he would like to add some functionality which was not originally designed for. Processes requiring Control may be added or removed. Control module might need to redefine zone granularity, priority between user satisfaction and energy efficiency. New simulation modules could be added, which in turn will require new materials attributes for the simulation. These new simulation modules might have been written in any language.

The last enforcer of system change is the emergence of new technologies. The functionality of the Java code which will support the sensor nodes within the VRML model may be extended in the future to support different communication protocols or deal with different methods of user input. In addition, the VRML browser itself may be enhanced to support input methods beyond the two-dimensional pointing device, such as speech or gesture recognition. The extension of the user input modes should be able to capture the exact meaning of user inputs while allowing a rather "ambiguous" input mode such as speech recognition. The integration of the User Interface with other input system such as Janus or SPHINX may require a significant amount of software "reengineering". Current simulation module may be modified to allow curved surfaces as input, which was impossible to deal with. More sophisticated CAD tools can be developed in the future. To deal with these situations, the system model should not be a static entity. It can be designed as much extendible as possible. The system components must also be as independent as possible. This allows them to be easily removed from the system without adversely affecting other components. This type of architecture will, for instance, facilitate integration of new CAD technologies as they become available.

Control hardware and real time video capturing devices in the Intelligent Workplace should be properly operated and maintained to reduce chances of errors or system faults. The light louvers, shades, and internal lights, and sensors are to be properly positioned and operable under facility manager's discretion. Specifically, Database needs a specialized machine room with "backups" housed in a physically distant location from the "primary" server(s). Un-interruptible Power Supply (UPS) should be provided to insure that a power failure does not endanger data consistency.

Other than the Database, OWLII is supposed to be accessible by any authenticated user on any machine networked. For example, 3D navigation and remote lighting system control could conceivably operate on any system meeting the hardware and software criteria to access to the Internet.

3.3.10 Security Issues

Other than the public demonstration of certain system services such as remote 3D navigation or building performance status monitoring of Intelligent Workplace, security in OWLII system is an important issue to be properly handled. OWLII security has to consider vicious and unauthorized changes on building representation model, data on Database, control settings, room schedules, and any critical system configuration. Unexpected changes could be made via a widely-available techniques and access methods through the network. The User Interface must be designed so that the system is protected from the interlopers. Depending on the privileges granted to the user, the Employee would be allowed to change the settings only in his office, while the Facilities Manager could change the settings anywhere in the building. In addition, the facilities manager will have some way of logging on remotely and changing settings. Alternate methods of access control can be investigated to allow more flexible system access. For example, by using password protection, a user may log in from any machine. This also could allow users access rights to change more than the environmental settings in their respective offices.

Only the Facility Manager and Building Designer will have full access rights to the CAD tool. The outcomes of their works are to be saved on Database. In addition, only the Facility Manager has authorization to change the main Intelligent Workplace model which describes the current state of the building. Other users such as average occupants in the Intelligent Workplace will be able to control their immediate environmental settings, make room reservations and delete reservations from calendars in addition to the access to the generic services OWLII User Interface provides. The deletion of reservations is limited to the owner of the reservation or the Facility Manager. The creation of reservations is limited to the Facility Manager and some authorized users. The Facility Manager must also deal with physical security, for he/she will have to make note of thefts and missing physical items. The building control server should be protected in a secure area to avoid physical tampering with the machine. The system itself is made to be externally accessible allowing the facility manager to remotely monitor the system. For the Database security, two types of actors that may access the Database can be defined: the Database Analyst and a remote process. Both these actors will have to perform an authentication step before any data access. This authentication, if successful, will give the actor a token which determines the adequate access rights. Only the Database Analyst may access the server both remotely and locally. In both cases, the analyst must be still authenticated.

3.3.11 Resource Issues

A software distribution containing the selected VRML runtime environment for 3D navigation

will be provided by OWLII system development team. Initial installation of VRML related data within the database will also be provided by the same team. But the maintenance of any commercial software packages such as VRML browser will be the responsibility of the client. Maintenance of the data stored within the database will be the responsibility of the body charged with administering the database. The OWLII system development team is also responsible for software system installation and deployment along with the interface to the given lighting control system such as Zumtobel’s Luxmate .

After the system delivery, the backup of the system will be handled by the selected System Manager and will occur on the schedule set forth by him or her. The System Manager will be responsible for system maintenance such as upgrading, calling systems programmers to debug system as well as assisting installation after the system delivery. Likewise, this System Manager will be responsible for the installation of the system. Installation and maintenance of the Database will be the responsibility of the Database Analyst. For this, the Database Analyst will be provided with an interface to the database that will allow her/him great flexibility. As a standard reliability measure, the system will have a backup mechanism. This will be the responsibility of the database system itself and will thus be transparent to all users. These automatic backups will happen periodically every day.

Java is the system-wide primary programming language because of its platform independent feature. This imposes us working around known and unanticipated bugs in Java. OWLII development environment was also constrained by the available development tools for Java so the design was affected by their bugs. Object communications are implemented mostly by RMI and by the Database subsystem's design and implementation. Zumtobel’s Luxmate was used as the lighting control system.

For the User Interface development, library support will be constrained by published VRML and Java libraries. User Interface will operate on and how the display looks is constrained by the web, Java, and VRML implementations available to us for specific hardware. For the Database development, the capability of handling object queries through CORBA(Common Object Request Broker) or RMI(Remote Method Invocation) has been evaluated over the candidate commercially available database management systems. And POET 4.0 was selected along with JAVA RMI connection.

The primary actors who are supposed to interact with the system are the Users such as Building Occupant, Facility Manager, System Administrator, and Remote Guest. Building Occupants are the faculties, staffs, and graduate students at Center for Building Performance & Diagnostics who will use the Intelligent Workplace as their major work environment. Facility Manager is the person who is responsible for the management, maintenance, and operation of Intelligent Workplace. Remote Guest is whoever wants to access to the system service remotely on the network. Additional type of actors could be introduced and even identified actor types might be decomposed into subtypes. The secondary actors are Sensor and Controller. Sensor could initiate notification event after capturing the abnormality of a specific building system or environmental change. Controller can be either PID algorithm or machine learning mechanism governing controlled processes such as lighting process or thermal process in the Intelligent Workplace. Sensor and Controller as actors were not fully incorporated into the current phase of system development.

A Building Occupant or an Remote Guest logs in the OWLII system. The key map window displays the most recent layout map of the building. User selects the area he or she is interested in from the key map and chooses 2D display mode. Selected portion of layout is scaled-up and displayed in the main visualization window including partitions and equipments. During this 2D visualization process, User also selects interesting areas or objects in the layout and other windows show either the real-time environmental conditions of the selected area with annotations attached to it or the information on the chosen object. Once user selects other zone, the same process is repeated with updated 2D view and its associated information.

When user selects 3D navigation mode, main visualization window is switched to VRML-based dynamic 3D image which user can navigate through by either the pointing device or voice commands . User's navigation path is traced also in the layout map of the auxiliary window while system keeps reloading updated scenes . Within a specific scene of 3D navigation process, user selects a "hotsopt" and pertinent information is displayed in other windows depending on the access rights of that specific user. This use case was not fully implementated.

An lighting fixture is broken(will be simulated). Luxmate system catches this unexpected event and notifies to OWLII system. In 2D layout window, the graphic element representing that Lighting Fixture turns red and starts blinking. Textual message "Light bulb # xxx is broken" is displayed

3.5.1.2.4. Lighting Control Zone Change Use case

Facility Manager selects two Lighting Fixtures currently belong to separate Spaces(will be simulated) and group them together by specifying them as a new control zone in the text edit window. When Facility Manager selects either one of them from the 2D layout, they are controlled integratively through the Luxmate switch interface.

5. Control System Name Service Use Case

Any type of User starts the system and the system automatically checks activated control servers distributed through different locations. User either implicitly or explicitly chooses the control server(s) which control command(s) is to be imposed upon. System enables the connection between User and the chosen control server to start a control session.

Facility Manager or an Occupant either locally or remotely logs in the system. If the User is an Occupant whose desk is in Luxmate controlled zone, the Luxmate lighting control interface is displayed and he/she defines a setting from the control configuration provided. Otherwise, a generic building control interface shows up for user to specify the various performance settings of his/her micro-environment. Once the control configuration is set by the User, it gets to the mapping control system and devices to activate control commands after global optimization by control algorithms. If the User is Facility Manager, he/she selects the zone or lighting device from the auxiliary window and chooses 2D display mode. Selected portion of layout is scaled-up and displayed in the main visualization window with pertinent control interface. Facility Manager sets lighting or other performance configuration(s) using the control interface and the system executes it through the relevant control infrastructure.

An Occupant either locally or remotely logs in the system. If the User is an Occupant whose desk is in Luxmate controlled zone, the Luxmate lighting control interface is displayed and he/she defines a setting from the control configuration provided. Once the blind control configuration is set by the User, it gets to the mapping control system to activate control commands. If the User is Facility Manager, he/she selects blind control zone from the keymap. Selected portion of layout is scaled-up and displayed in the main visualization window with control interface. Facility Manager sets blind configuration(s) using the control interface and the system executes it through the relevant control infrastructure.

Object models are attached to the javadoc packages with navigational texts.