System Design Document

STARS Project

15-413 Software Engineering

Fall 1999

Carnegie Mellon University

Pittsburgh, PA 15213

Revision History:

Preface:

This document addresses the design of the STARS system. The intended audience for this document are the designers and the clients of the project.

Target Audience:

Client, Developers

STARS Members:

Kevin Babbitt, Nathan Bingham, Bernd Bruegge, Bill Scherlis, Timothy Canfield, Paul Cassella, Jason Chalecki, Patrick Ditterline, Zeb Drivdahl, Richard Ekwall, Michael Fortson, David Garmire, Daniel Gindikin, Rachel Goldstein, David Guttendorf, Tom Hawley, Daniel Heller, Roger Hong, Joyce Johnstone, Jeremy Jones, Robert Kurian, Alexander Kutner, Patrick Larkin, Christopher Lee, Mark Marrin, Kaushik Merchant, Brian Parkinson, Fani Pavlova, Graham Prud'homme, Li Qiu, Grace Ritter, Jonathan Rosenberg, Pooja Saksena, Paul Shao, Brian Showers, Roger Smith, Eric Stein, Zia Syed, Leong Teo, Stephen Verleye, Matthew Weyant, Tracy Wortham, Yik Lin Khoo, Anthony Yip, Cheng Zhao, Adi Zukerman

• 1. Goals and Trade-offs
• 2. Subsystem Decomposition
• 3. Concurrency Identification
• 4. Hardware/Software Mapping
• 5. Data Management
• 6. Global Resource Handling
• 7. Software Control Implementation
• 8. Boundary Conditions
• 9. Design Rationale (Incomplete)

1. Goals and Trade-offs

1.1 Overview of STARS System Design

The goal of the Sticky Technology for Augmented Reality Systems (STARS) project is to create an end-to-end solution for organizations using interactive electronic technical manuals (IETMs). STARS focuses on the authoring and maintenance processes as these are the activities that will have the largest impact from the use of IETMs. The United States Navy is the client for the initial development of STARS, though the STARS architecture is extensible to support its use in other application domains. This document presents the technical details of the STARS system design. More information about the motivation or features of STARS can be found in the Problem Statement and Requirements Analysis Document (RAD), respectively.

For the electronic manual creation process, STARS facilitates organizations in creating and integrating IETMS in a more efficient manner than is currently practiced. The current practice in the US Navy is to have the prime contractor deliver the integrated manuals, which may include content generated by many different subcontractors. STARS provides an alternative to this process by having all of the contractors on a project transfer their content directly to an integration database operated by the US Navy, where a finished IETM is generated. STARS streamlines the authoring and review processes without sacrificing the quality of the documentation produced. STARS also helps to manage the distributed authoring of electronic manuals across many contributing organizations by tracking the progress of content creation and aiding the transfer of content from one organization to another.

In the maintenance process, STARS aids the mechanic by providing an integrated view of IETMs, workorders, and schematic wireframe diagrams. This includes advanced IETM navigation and the ability to add location information to workorders through the use of "stickies". Stickies might be used to provide a more specific description of a discrepancy found during an inspection than would be allowed in text. For example a sticky could mark the exact spot of corrosion on the airframe of a plane. STARS leverages advanced technology to provide alternative ways for the mechanic to interact with the computer through the use of data gloves, head mounted displays, wearable computers, speech synthesis and speech recognition.

1.2 Design Priorities for STARS

The design priorities within STARS are largely limited by the short period of time within which the system must be completed. Due to this fact and the further limitation on the implementation phase itself, development time is the highest priority of the STARS system.

The STARS system is also an ongoing project which will be repeatedly passed between teams of developers and is thus undergoing distributed development. Therefore, it is critical that the system be designed with this process in mind. This leads us to the next three design priorities within STARS: reusability, thorough documentation, and extensible design.

The system must be reusable so that future developers can quickly and easily understand and expand the system without an extreme learning curve. Thorough documentation will allow both the client and other developers to understand the rationale behind design decisions and the interactions between subsystems. An extensible design allows developers to easily add further functionality that is not implemented in the first phase of development and simplifies the alteration of current functionality to meet future needs.

Industry standards were used as much as possible in STARS development where requirements were not otherwise. Some of the sandard APIs and technologies used in STARS include JDBC (Java Database Connectivity), JSAPI (Java Speech API), Java3D, and XML (Extensible Markup Language). This allows STARS to easily interact with commercially available software and change some of the underlying software (for JDBC and JSAPI).

Finally, the functionality of the STARS system will be constrained by the above requirements and will be implemented as time allows. The portability of the system is relatively assured by the use of the Java programming language for implementation.

1.3 Tradeoffs in the Design of STARS

There are many tradeoffs involved in the design of STARS. A few of the more important ones are discussed here.

Clearly functionality and development time are competing priorities. Due to the short time frame of the first phase of STARS development, the STARS development team is focused on developing the core features of STARS and providing a solid design that will allow more advanced features to be easily integrated into the system. An analysis of the core and advanced requirements, by development team, can be found in each team's Requirements Analysis Document

The storage of persitent data in STARS is done with a general document storage framework. This generalized storage solution is provided by the database subsystem. It was decided to use a generic mechanism for data storage to reduce duplication of effort, even if the idea of a "document" didn't apply to all persisten data storage.

Another tradeoff is represented in the refresh rate of the wireframe display against the complexity of the model for the wireframe. The wireframe viewed by the wearable computer user should refresh often (up to 24 frames per second). At the same time, the model should accurately reflect the physical objects that the user is interacting with, which results in a more complex model which is more computationally expensive. It has been determined that accurate representation of the physical world is more important, and model complexity is favored over refresh rate, down to a minimally acceptable refresh rate (about 5-10 frames per second). The use of a wearable computer places resource limitations on STARS, which result in a design tradeoff for any processor intensive task. The statistics of the wearable computer will be vastly different by the time STARS will be used in the field, and it is anticipated that this issue will become less important over time.

The mechanics will be performing maintenance on aircraft carriers at sea, and there will be times when will need to operate under "Emission Control" (EC). Emissions control means that radio broadcasts of all kinds must be limited. The restriction of having to operate under EC has led to the decision that the system must be able to operate completely disconnected from any database during a maintenance session. This means that a mechanic needs to have all of the information that he/she needs for maintenance on his or her wearable computer. If not, then the mechanic may need to return to a docking station in the middle of maintenance in order to continue. The impact of the restriction is highly dependent on the application domain and the typical use patterns of the system in that setting. Communication with the server will be possible via wireless networking when EC is not in effect.

As is the case with all wearable computers, user interface tradeoffs have to be made due of the types of input methods available. The STARS system mechanics will use the positioning/orienting device to serve also as a general pointing device (analogous to the traditional mouse) and restrict other input to either speech and/or a joystick/trackball with a few buttons. A mechanic can interact through speech interface if he/she decides that wearing the HMD is too cumbersome or clumsy.

The view presented to a mechanic during maintenance provides another tradeoff. The IETM, workorder, and wireframe diagram all need to be accessible to the user. There are multiple window approaches where only one component can be seen at a time, multi-frame approaches where all components are visible but with lower resolution than if displayed one at a time, and hybrid approaches. Usability testing will need to be done to identify what approaches are best suited for the maintenance process.

A primary concern of the US Navy is to reduce the cost of authoring IETMs. This must be balanced against the need that all of the manuals produced be correct and complete. The authoring process has been designed to be as efficient as possible while still providing multiple rounds of quality control to minimize the number of errors in the generated IETMs.

2. System Decomposition

2.1 System Decomposition

Authentication

The Authentication subsystem is responsible for checking the credentials of the users of the STARS system and verifying their identity. The users and their credentials are stored in a Lotus Notes database.

Authoring

The Authoring subsystem provides the tools authors and quality controllers need to work together to create high quality IETMs. The Authoring subsystem interfaces with external programs that authors use to create content. The Authoring subsystem also provides quality controllers with an interface for reviewing and annotating documents.

The Authoring subsystem is dependent on the Database subsystem and implicity the Notification subsystem. The Database subsystem provides storage for documents to be shared by the users of STARS, and the Notification subsystem provides a mechanism for documents to move from one user to another.

Database

The Database subsystem provides a document storage framework for the rest of the STARS subsystems. Documents can be stored, retrieved, updated, and searched, among other things. The Database subsystem also manages access control for all of the documents that are being stored. The Database subsystem is responsible for handling the network communication between client machines and the server. Access to the services of the Notification subsystem is also provided.

The database subsystem is dependent on the Notification and Authentication subsystems. Every STARS user must be authenticated before accessing the database. Users can only be notified when documents are created or changed in the database.

Maintenance

The Maintenance subsystem provides the graphical user interface to do an inspection based on IETMs. The mechanic will be able to navigate through the IETM, following its instructions, and add a sticky to a repair location when a discrepancy is discovered. This is done by pointing to a specific location of the airplane, indicating the discovered discrepancy and the type of repair.

The Maintenance subsystem depends on the database subsystem for storage of workorders and stickies, as well as for retrieving IETMs. The Maintenance subsystem also depends on the Modeling subsystem to get the coordinates for a sticky when it is being placed. The User Interface subsytem is used to display the views of the IETM, workorder, and sticky.

Modeling

The Modeling subsystem provides a wireframe view of the equipment being worked on, overlaid with graphical representations of sticky notes associated with the current workorder. The view of the equipment adjusts in real-time based on the orientation of the user. The Modeling subsystem also translates between the two dimensial coordinates of the screen and the three dimensional coordinates of the model when a sticky is placed.

The Modeling subsystem depends on the Orientation subsystem to get the the orientation of the current user. This is done by "listening" to the events generated by the Orientation subsystem. The Modeling subsystem also depends on the User Interface subsystem to display the panel with the wireframe drawing of the equipment. The database subsystem is used to store the data for the model.

Notification

The Notification subsystem is responsible for notifying users about changes to documents in the database. The list of users and their contact information is located in a Lotus Notes database.

Orientation

The Orientation subsystem provides information on the mechanic (and his/her wearable computer) in the form of Vector events which contain the position and orientation of the mechanic. The Orientation subsystem is responsible for interfacing with the various hardware that provides the information contained in the Vector events.

Speech

The Speech subsystem provides speech navigation through workorders and IETMs. The Speech subsystem uses the services of the Maintenance subsystem to navigate workorders and interfaces with the IETM viewer (Web Manual) to navigate IETMs. The speech recognition engine will accept a limited grammar for navigating workorders and IETMs, and the text of the workorder or IETM can be read to the mechanic using speech synthesis.

The Speech subsystem depends on the Maintenance subsystem to provide navigation of workorders.

User Interface

The User Interface subsystem manages the display presented to the user of a wearable computer.

Workorder

The Workorder subsystem is mainly responsible for creating workorders out of the stickies generated during an inspection. This workorder is then submitted to the database and the appropriate users are notified.

The Workorder subsystem is dependent on the Database subsystem to provide storage for workorders and stickies.

2.1.1 Layers & Partitions

Figure 1: STARS subsystem dependencies

The dependencies between subsystems in STARS are shown in Figure 1. The lines indicate dependencies, with the lines originating at the dependent subsystem in each relationship.

2.1.2 System Topology

Figure 2: STARS Deployment Diagram for the IETM authoring process

The diagram in Figure 2 shows the different nodes involved in the authoring of IETMs. Every organization creating content for IETMs has an Authoring Database, and once a document has been approved by quality control, it will be transferred to the Integration Database, where different documents will be compiled in to a finished IETM. When the finished IETM is approved by quality control, it is transferred to the field databases where it is used by mechanics. Note that all of the subsystems and components in the integration and field database nodes are not shown only to save space. Also note that the replication of IETMs to the field databases is out of the scope of the STARS project.

The Database subsystem in the authoring process will contain databases for each type of document created during the authoring process, such as DigitalDocs and IETMs.

Figure 3: STARS Deployment Diagram for the maintenance process

The diagram in Figure 3 shows the different nodes involved in the maintenance process. The mechanic will download the workorder and IETMs necessary to complete an inspection to his/her Portable Electronic Display Device (PEDD). The mechanic then performs the inspection as described in the IETM and attaches any stickies necessary to the workorder. The workorder is then updated in the database so that is can later be used by a mechanic to repair any discrepancies found. The mechanic will be able to view the stickies for the current workorder on top of wireframe of the equipment being repaired, using the services of Augmented Reality and Modeling.

In this diagram, the wearable computer on the left represents the typical setup, while the wearable computer on the right shows the situation when the speech interface has been activated. Once again, the details of the database have not been shown to conserve space. The Database subsystem in the maintenance process will contain databases for IETMs, stickies, workorders, and the model of the equipment.

3. Concurrency Identification

Workflow Team:

• The independent objects in the Workflow subsystem are the Database, the Inspection subsystem, the Repair subsystem, and the Authoring subsystem.
• The following control threads have been identified:
1. There is a control thread which handles incoming events from other subsystems.
2. There is also a control thread administrating the database.
• The Workflow system provides access to multiple users. The Authoring, Inspection, and Repair subsystems may be accessing workflow at the same time.
• A single query does not consist of multiple queries. However, multiple queries must be handled in parallel by different subsystems. For example, a user from Authoring may be updating a document at the same time as an inspector is attempting to download workorders. Potential problems for this subsystem exist when several users attempt to update a document at the same time.

Authoring Team:

• The independent object in the Authoring subsystem is the Workflow subsystem
• The following control threads have been identified
1. There is a control thread that handles requests from the other sub-systems
2. There is a control thread that handles Workflow's notifications
• Authoring may submit multiple documents at the same time, resulting in a concurrency issue for workflow.
• One special case is when a document is open and being edited by two people.
• Internally the Authoring Group has an issue is they get two requests for Annotations for a correction to a document and the corrections do not agree with each other. One says change the wire color to blue, the other to purple. Though this is about External requests to their system.

Modeling Team:

• The independent objects within the modeling subsystem are Location, simply a coordinate location for some object within the wireframe model; Component, a specific section of the wireframe model; and Sticky, a discrepancy reported from an inspector.
• Modeling requires two separate control threads that allow access into databases maintained by workflow:
1. Modeling provides an interface into the workflow sticky database.
2. Modeling provides an interface into the database containing the information for the wireframe model.
• Multiple users can add, access, alter, and remove stickies concurrently. In addition, multiple users can download applicable wireframe components, but there is no concurrent alteration of the wireframe database. In both cases, the concurrency issues will be handled by the workflow subsystem which is doing the actual database management.

Augmented Reality Team:

• The independent objects acting within the Augmented Reality subsystem include input devices such as a joypad or any positioning device.
• The Augmented Reality subsystem will definitely make use of one major control thread; most of the functionality of the AR subsystem will be event handling and passing on information to other subsystems (such as Inspection and Repair) for interpretation. With this in mind, the following threads of control can be identified:
1. Hardware device interface, main event handling thread
2. Interaction with Inspection and Repair subsystems via separate threads of control
• Multiple users are not supported. The AR subsystem resides wholly in each PEDD, and the scope of that system is local to the aircraft being worked on. There will be one user per PEDD, although multiple PEDDs could be checked out there will be no synchronous assignments on any aircraft.
• Since the Augmented Reality subsystem is designed primarily to be event driven, most queries will have not lead to multiple queries. In some user interface and display situations it is possible that one query will lead to multiple queries (ie multiple views of the same information change when one view's information changes). This effect will be corroborative effort of the owners of these interfaces; AR will handle the events causing such a change, but view synchronization will probably be other subsystems' responsibility.
• The Augmented Reality subsystem is viewed to be paired with one PEDD and also one plane. It will not be possible for another PEDD to simultaneously query the same information, although another PEDD might be in use on another plane (considered its own private environment for activity). AR is using an event based model, and handing off events for processing to the appropriate PEDD resident subsystem (ie in an inspection situation, the inspection subsystem will receive all events, and respond with relevant processing information). There should be no concurrency issues within the scope of the AR subsystem.

Inspection Team:

• The independent objects in the Inspection subsystem are the Sticky, the Workorder, the Workflow and the Inspection Inteface and the Augmented Reality System Interface (all defined in section 3.5.3 of the Inspection RAD).
• The following control thread has been identified:
1. Thread controlling the main flow of events. This thread is created at the beginning of the inspection. This thread also controls the User Interface.
• The inspection subsystem provides access to one inspector at a time. A PEDD can only be used by one inspector at a time. Many PEDDs can be active at the same time.
• One query can consist of multiple queries. For example, when placing a sticky, a query is sent to the Augmented Reality system to get the current position. Another query is sent to the User Interface to display a form to be filled in by the inspector.
• Inspection does not handle different queries in parallel. One query is handled at a time.
• There is little or no concurrency in the Inspection Subsystem. An inspection is sequential. Actions are performed one after the other, and there is no real use of being able to perform several tasks in parallel.

Repair Team:

• The only independent objects in the Repair subsystem are the "User" and the "LotusNotesDB" (section 3.5.3.2 in the Repair RAD)
• The following control thread has been identified:
1. The current flow of events in the repair procedure is managed by a thread. This thread is created at the beginning of the repair procedure. It also controls the User Interface.
• The repair subsystem provides access to one repair person at a time. There can not be more than one mechanic using a PEDD at a given time. Of course, many PEDDs can be used at the same time.
• One query can consist of multiple queries. For example, when a speech command is issued, it will send a query to the UI and to the thread in charge of handling the current flow of events.
• Repair does not handle different queries in parallel. One query is handled at a time.
• There is not much concurrency in the Repair system. The flow of events is sequential and involves little or no parallelism. The GPS is called only when it is needed. There is therefore no need for a dedicated GPS thread.

4. Hardware/Software Allocation

The current system in place for equipment maintenance by the US Navy is a paper and pencil system by which inspectors and mechanics mark defects on an aircraft and then write workorders for their repair.

STARS will be implemented Java and run on Microsoft Windows 98. Java provides an object oriented design environment and is platform independent. Java is also extensible and allows developers to interface with almost any external system. If a Java API does not already exist for an external system, it can be created using the Java Native Interface (JNI). This is likely to be needed in to use the hardware that will used to gather position and orientation information.

The authoring subsystem is responsible for automating the creation and integration of Interactive Electronic Technical Manuals (IETM), a process which would otherwise be done at great cost by the Original Equipment Manufacturers (OEM). The database subsystem provides a way to store IETMs in a database for search and retrieval by maintenance personnel, and to provide an interface to view the IETMs. The orientation, modeling, and maintenance subsystems will provide a wearable computerized system to display workorders, specific repair orders, and repair instructions. The user interface subsystem will provide user interface management. The modeling subsystem will provide a wireframe of an aircraft, along with a way to navigate/view the wireframe. The speech subsystem will focus on voice command and speech recognition.

Here is a table of each subsystem, and their specific hardware and software utilization (excluding JDK 1.2):

Subsystem	Hardware	Software
Authentication	none	Lotus Notes
Authoring	none	Authoring Tools: GCS, ACS, AIMSS (3.2 and 4.0)
Workflow	none	JDBC, JDBC-compatible database (MySQL)
Maintenance	none	Web Manual
Modeling	none	Java3D
Notification	none	Lotus Notes
Orientation	head mounted display, positioning system, orientation gyroscope	OEM drivers
Speech	microphone, headphones	Web Manual, JSAPI, JSAPI-compatible voice recognition software (IBM ViaVoice)
User Interface	joypad	none
Workorder	none	none

4.1 System Performance

4.1.1 General System Performance

STARS is an interactive system and must respond to user requests quickly, on the order of a second or two. Some subsystems are more time critical, such as the modeling subsystem. Aside from the general need that the system be responsive to the user, some of the requirements are listed below.

Modeling
The most time-critical process is the manipulation of the wireframe object, which must be calculated and displayed in realtime. The desired refresh rate is twenty-four frames per second, the same display rate used for motion pictures, which takes into account user comfort and environment. Taking into account overhead of hardware calls, the rotation of the wireframe must be calculated and displayed in no more than three hundreths of a second.

Orientation
The Vector events produced by the Orientation subsystem need to be generated at the frame rate of the model, 24 frames per second.

Database
The majority of the processing time of the Database subsystem will be spent transferring documents over the network, and therefore is dependent on network traffic. On a network with low traffic though, the Database subsystem should be able to transfer documents at at least 200 Kilobits per second.

Speech
Obviously, the Speech subsystem needs to recognize the speech of the user in real-time. It is unacceptable for the Speech subsystem to fall behind or to skip spoken commands.

Notification
The Notification subsystem is currently notifying STARS users via electronic mail, so the response time of notifications is dependent on the mail systems in use. The email notification should be sent out immediately after the database is updated though.

4.1.2 Input/Output Performance

The performance of the modeling subsystem would benefit from dedicated 3D acceleration hardware. Unfortunately no such hardware exists for the wearable computer platform used in STARS. If such hardware becomes available it should be considered for use in STARS. No other subsystems should require dedicated hardware to meet their performance needs.

4.1.3 Processor Allocation

Wireframe manipulation and speech recognition are the two most processor intensive operations, and are expected to utilize most of the CPU time. However both processes should be able to coexist on the same processor with close to acceptable performance.

4.1.4 Memory Allocation

The wearable computer used in STARS has 64 MB of RAM, which will be enough for the operationg system (Windows 98), the Java Virtual Machine, and ViaVoice to run. The wearable computer currently has 680MB of hard disk space which is much more restrictive. In the near future the hard disk will be over 1GB, which we be enough for all data that needs to be stored on disk, so the current hardware is being used for development.

4.2 Connectivity

Figure 4 shows the connectivity of the different hardware used in STARS. The top half shows the authoring process, which consists of many authoring workstations connected to a database server.

The bottom half shows the connectivity during the maintenance process. A wearable computer (PEDD) is worn by a user. A head mounted display, joypad, microphone, speakers, positioning device, and orientation device are attached to the PEDD and also worn by the user. The PEDD is connected to a database through wireless communication (with wired communication as a backup).

The only repeated components are the multiple PEDDs used by the mechanics and inspectors. They do not interact directly with each other, and the database which they connect to supports concurrent uploads and downloads and workorder locking.

Figure 4: STARS Connectivity Diagram

4.3 Network Architecture

Here is a table containing the network connections, transmission media, and transmission protocols. All connections are asynchronous. There is no constraint on required bandwidth, except that the fastest media should be used wherever practical to increase user productivity.

Source Device	Target Device	Transmission Media	Transmission Protocol
Authoring workstation	Authoring database	100baseT ethernet	TCP/IP / Remote Method Invocation (RMI)
Wearable Computer (PEDD)	Field database	10baseT ethernet, wireless ethernet	TCP/IP / Remote Method Invocation (RMI)
local hardware devices (joypad, speakers, microphone, HMD, etc.)	PEDD wearable computer	cable connection	proprietary protocol
positioning/orientation devices	PEDD wearable computer	serial cable connection	proprietary protocol

Wireless communication is not always reliable, especially given the target environment in which this system will be used. Therefore, a redundant wired system will also be implemented. Though inconvenient, it provides functionality to the system when the wireless communication channel is unavailable due to failure, electronic noise, emissions control, etc.

5. Data Management

5.1 Types of data

Data managed by the Workflow subsystem is stored in Lotus Notes databases. Two such databases exist. The first is used to store IETMs and annotations to them during and after the conversion process; the second is used to store workorders and sticky notes associated with them.

"Flat" file data is stored in file formats pertaining to the nature of the data. Existing standards are used where possible. As of this writing, the only such data is the CAD model of the aircraft, used in generating wireframe images, which is stored in AutoCAD format.

5.2 Storage spaces

The Workflow database server holds the Lotus Notes databases for IETMs and their annotations as well as the database for workorders and their associated stickies. The former database is updated whenever newly converted or annotated IETMs become available as described in section 4. The latter database is updated when new workorders are generated, for example by an inspector who has just completed an inspection cycle while wearing a PEDD. The details of the information transfer are also described in section 4.

The PEDD's fixed-disk storage carries the executable code for the STARS system, user preference data, and "flat" data as described above. This storage space is baselined from a standard information store via a hard disk flash. Before a maintenance operation (inspection or repair), information such as workorders and IETMs are downloaded to this space from the Workflow server for use. At the end of this operation, new workorders with associated stickies are uploaded back to the Workflow server from the PEDD.

The PEDD's RAM, obviously, holds transient data. This includes code that is currently being run, the active workorder and IETM, and portions of the CAD model currently needed for display. Data in this space is managed by the PEDD's operating system (most likely Linux) and by STARS software.

5.3 Workflow database access

6. Global Resource Handling

6.1 Authentication

6.1.1 Authentication System

Authentication is required for access to every subsystem request, independently. To date, there are no plans for any global handling of authentication tokens.

6.1.2 User ID

Each user is assigned a unique user ID that they use to gain authentication to the different subsystems. The user id should be consistent across all subsystems for a particular user.

6.1.3 User Password

6.1.3.1 Password Encryption

The password should be encrypted using the existing military system for encryption.

6.1.3.2 Password Caching

The user ID and password are stored in memory on the local machine and deleted from the machine when the user logs off or the power supply is interrupted. To access information from the database a user must be authenticated by sending the system his user ID which uniquely identifies him on the system, and a password. This information is cached on the local machine (a wearable computer or workstation) and used to authenticate with the server when a request to any other subsystem is issued, the server then decides whether the user has enough privileges to execute that request.

6.2 Hardware/Software Resources

6.2.1 Server Hardware/Software Specifications

6.2.1.1 Processor

The server will require one or more high-performance processors.

6.2.1.2 Memory

The server will require incredible amounts of memory, on the order of a GB of RAM.

6.2.1.3 Storage

The server will require between 100 and 300 GB of hard drive space to store IETMs and STARS documents.

6.2.1.4 I/O

• Network connection: The server will require a high-bandwidth connection for transferring IETMs and other STARS documents.

6.2.1.5 Software

The server must be able to run Lotus Notes Database.

6.2.2 Wearable Hardware/Software Specifications

6.2.2.1 Processor

The wearable computer needs a processor capable of displaying IETMs, running a speech engine, and displaying complex 3-dimensional models concurrently. This would require a high-performance processor such as a Pentium II 450 MHz.

6.2.2.2 Memory

The wearable computer will require substantial amounts of memory. It should be equipped with at least 128 MB of RAM.

6.2.2.3 Storage

The wearable computer will require at least 1 GB of hard drive space for installed programs and required data files.

6.2.2.4 I/O

• Visual display: The wearable computer will provide a head-mounted display (HMD) supporting a minimum resolution of 800x600 (SVGA).
• Network connection: The wearable computer must have a wireless network connection with a bandwidth of at least 10 Mbps.
• Speech I/O: The wearable computer should have a microphone capable of picking up speech from large amounts of ambient noise. It should also have a headset that will allow the user to hear synthesized speech in the same environment.
• Joypad: The wearable computer should have a pointer input device with at least 2 buttons, similar to those typically found on a laptop computer.
• Additional I/O:
  • There should be a keyboard port for entry of authentication information.
  • 1 USB Port
  • 1 Serial Port
  • 1 Parallel Port

6.2.2.5 Power Supply

The wearable computer will be battery-powered. The battery will have a minimum life of 2 hours.

6.2.2.6 Operating System

The wearable computer should be running Windows 98 and be able to run a JDK 1.2-compliant JVM.

6.2.3 Authoring Hardware/Software Requirements

6.2.3.1 Processor

The authoring workstation will require a mid-level processor such as a PIII-450.

6.2.3.2 Storage

The authoring workstation will require about 10 GB of hard drive space each workstation for documents.

6.2.3.3 I/O

• Network connection: The authoring workstation will require a high-bandwidth connection for transferring IETMs and other documents.
• Scanners: The authoring workstation must be able to use standard scanning equipment.

6.2.3.4 Software

The authoring workstation must run Windows NT and be capable of running OCR editors.

6.3 Other Unique IDs

6.3.1 IETM ID

Each IETM has a globally unique ID that identifies it on the system. This ID can be used to reference an IETM from any other subsystem. This will be the preferred identifier to reference any given IETM.

6.3.2 Workorder ID

Each workorder has a globally unique ID that identifies it on the system. This will be the preferred identifier to reference any given workorder from another subsystem.

7. Software Control Implementation

7.1 External Control Flow

Typically, flow control starts with user interaction with the STARS system, though there are a few exceptions to this. The Authoring, Inspection, and Repair subsystems are responsible for a bulk of the interactions outside of the system, and therefore initiate the flow of control through the STARS system. Authoring interfaces with the document creation and editing tools and Inspection and Repair interact with users through traditional input devices and also via speech input. Another source of control flow through the system is the timers that reside in the Workflow subsystem for notification purposes.

There are likely to be many threads on any node in that is part of the system. There is a thread that is exclusively for handling and dispatching user interaction events. For the wearable computers, there is a thread handling speech recognition. On user nodes there is a thread within the Workflow subsystem dedicated to fetching documents. On server nodes a thread pool or thread-per-connection approach is used to handle requests from other nodes.

7.2 Concurrent Control

The STARS system is highly concurrent (see Section 3). All access to the workflow subsystem can happen concurrently as multiple technical manual writers, quality control experts, and maintenance personnel all access data stored in the workflow databases. The only non-concurrent actions involving the workflow database is that documents can not be opened for writing by multiple parties at the same time.

Outside of the central database, the maintenance subsystem also allows multiple repairmen to access and use workorders, and more than one inspection person may be entering workorders into the system. Furthermore, a repairman may be transferring a work order either to or from the database while accessing one already on his handheld device.

7.3 Internal Control

• Workflow: The Workflow subsystem is based on procedure driven control. Depending on the configuration of the node (user or server), a single thread or a pool of threads for handling requests is created. When other subsystems call a Workflow procedure, one thread is assigned to carry out that task. When it has been completed, the result is returned to the caller, and the thread is either terminated or added back to the pool of available threads.
• Repair: There is only one thread in the Repair subsystem. The speech engine notifies this thread whenever the user speaks a word. This thread then dispatches the information to another thread that carries out the appropriate action. The thread is then free to continue waiting for the next speech input.
• Inspection: The Inspection subsystem is based on procedure driven control. There are no threads within the Inspection subsystem, and processing is done using the threads that use the procedures of the Inspection subsystem (typically the UI thread).
• Authoring: The authoring subsystem makes use of procedure driven control. The path of a document takes from paper to IETM really does not allow for event driven models or a multi-threaded environment.
• Modeling: The Modeling subsystem also makes use of procedure driven control. The subsystem is called with an empty panel, which they fill with the appropriate information. There is not multiple threads.

7.4 User Interface

• Augmented Reality: The Augmented Reality subsystem provides a User Interface Manager. Each subsystem wishing to interact with the user via the PEDD provides the UI manager with a window to display, and requests from the UI manager data from the various input devices and notification of user events.
• Authoring: The Authoring subsystem provides an interface to the conversion of paper technical manuals to IETMs. This interface does not interact with Augmented Reality's UI manager.
• Inspection: The Inspection subsystem provides an interface to the generation of workorders. It requires from the UI manager access to a positioning device, such as a GPS bracelet, for determining the position of placed stickies.
• Repair: The Repair subsystem provides, by way of Augmented Reality's UI manager, an interface for navigating a work order in order to carry it out. Speech recognition and speech synthesis are used for parts of the input and output, respectively. A visual depiction of the work order is also provided.
• Modeling: The Modeling subsystem provides a way of displaying a wirefrom model with stickies. The user is able to navigate through the model by changing the location and orientation of the viewer. This view can be displayed through Augmented Reality's UI, with the location given by the positioning devices used to drive the navigation. It receives notification when the view of the model needs to change, such as when the inspector moves or adds a sticky.
• Workflow: The Workflow subsystem does not have a user interface.

8. Boundary Conditions

8.1 Initialization

Initialization must be done in at least two steps. The first step will be the initialization of all of the communication and connectivity provided by the Database Sub-System. The second step arises because all other groups require those services to function correctly. Therefore, once those services are started, all other subsystems can perform their initialization. A sequence diagram showing the initialization of the PEDD can be seen in figure 5 (without the speech subsystem). The initialization of each of the sub-system occurs as follows:

• Authoring Sub-System
  • Either a Paper Document must exist which is to be converted into an IETM or an Annotation must arrive from outside the Sub-System for an IETM.
• Database Sub-System
  • The first time the database subsystem is run, it must be told to initiatlize the database.
• Augmented Reality Sub-System
  • Since the Augmented Reality Sub-System is a "service provider", it is not required that other subsystem start before the Augmented Reality Sub-System does. Anyone wanting to use the services provided has to be up and running to make the request. The Augmented Reality Sub-System is expecting to be given User Interface(s) from Modeling, Inspection and Repair. Of course to have a "useful" Augmented Reality system, we need at least Modeling to add their wireframe user interface to us.
  • Again, being a "service provider", the Augmented Reality Sub-System does not require data from other Sub-System to start. All data that the system needs to bootstrap itself are internal to the system, e.g. positioning and orientation devices will provide the vector events.
  • The user interface is still being work out by the new User Interface team. Being the manager of the Sub-Systems' user interfaces, our contents is really defined by the other Sub-Systems. Augmented Reality will partition the screen space into fixed partitions to display the user interfaces provided by other Sub-Systems. Part of the Augmented Reality user interface will be ways to manipulate these screen partitions (e.g. full screen mode)
• Inspection Sub-System
  • Augmented Reality Sub-System starts up the Inspection Sub-System.
• Modeling Sub-System
  • The Database Sub-System and the Augmented Reality Sub-System need to be started before the Modeling Sub-System.
  • Modeling needs information on the configuration of the aircraft being viewed, what stickies are currently attached to that aircraft, and an initial position/direction "camera angle" vector.
• Repair Sub-System
  • Requires the Inspection Sub-System to be running before the Repair Sub-System.
  • A workorder and the stickies associated with the workorder must exist for the Repair Sub-System.

Figure 5: Sequence Diagram of Initialization of Subsystems on the PEDD

8.2 Termination

Termination is very Sub-System dependent.

• Augmented Reality Sub-System
  • When the Augmented Reality Sub-System terminates, all other sub-system (e.g. modeling) will stop receiving input events (e,g, vector events), except for Repair and the voice input which can continue feeding voice input.
• Authoring Sub-System
  • Termination occurs when the Annotation-Free IETM is created.
  • The new IETM exists in the Database Sub-System.
• Inspection Sub-System
  • Termination occurs when the Inspection is over
  • Any stickies that were created are added to the database
• Modeling Sub-System
  • Termination occurs when the Augmented Reality Sub-System terminates.
• Repair Sub-System
  • Termination occurs when the Repair is over.
  • The workorder is updated to show that it is completed
• Database Sub-System
  • The Database Sub-System should not terminate under normal conditions. It should always be available for other subsystems to connect to.

8.3 Failure

Failure is NOT an option.

• Augmented Reality Sub-System
  • The Augmented Reality Sub-System does not communicate outside of the PEDD. So the system is not directly affected by a communications failure. Our communications failure will be a case of breakdown in the API, e.g. we cannot make method calls to objects.
• Authoring Sub-System
  • If the failure is internal, try to recover via the Version Control System. If the recovery fails, restart the Sub-System.
  • If the failure pertains to the Database Sub-System, local copies will be saved so as to prevent the loss of data.
  • Failure of any other Sub-System has no effect on operations of the Authoring Sub-System.
• Inspection Sub-System
  • If the failure is in the Database Sub-System, the Inspection Sub-System must wait until the Database Sub-system comes back up to download the IETM
• Modeling Sub-System
  • Augmented Reality Sub-System is responsible for calling Modeling to update the wireframe as needed. If communication with Augmented Reality Sub-System goes down, the Modeling Sub-System has no way of continuing to update the display.
• Repair Sub-System
  • If the Database Sub-System is down, the mechanic can work off-line since the workorder will be cached and submit to the Database Sub-System once it is functioning again.
• Database Sub-System
  • In the event of a network failure, any notifications that need to be sent will be queued up, and notification will occur when the network comes back online. Obviously, if there is no network, communication to and from the other Sub-Systems will be unavailable.
  • It is unlikely that there is are any special requirements if another Sub-System fails. However, in the event of a system-wide failure, some issues could arise. However, at this time it is uncertain if all of the necessary machinery for true err or recovery is going to be implemented in this phase of the project.

9. Design Rationale