Requirements Analysis Document

STARS Project

This document contains only the parts of the RAD
created by the Repair (Maintenance) Team

Revision History:

Version R0.1 10/7/99 Steve Verleye. Created

Version R0.2 10/19/99 Pat Larkin. revised RAD

Version R1.0 10/20/99 Repair Team, revised RAD

Preface:

This document addresses the requirements of the STARS Repair subsystem. The intended audience for this document are the designers and the clients of the project.

Target Audience:

Client, Developers

STARS Repair Members:

Mark Marrin, Pat Larkin, Steve Verleye, Jason Chalecki, Rachel Goldstein, Sam Chong

1.0 General Goals

The repair system is a way for F-18 mechanics to access work orders, general repair documentation, and information about the status of the airplanes they are working on from a portable computer through speech commands. This documentation will also be available on a display unit.

2.0 Current System

The current plane documentation and work allocation system is paper based. Interactive Electronic Technical Manuals (IETMs) are being compiled for inspection and repair usage. There are a number of IETMs currently available.

3.0 Proposed System

3.1 Overview

The repair subsystem will enable mechanics to quickly access task-related documentation about the aircraft he or she is assigned to repair. The system will include a wearable computer capable of displaying repair procedures and related diagrams. Mechanics will be able to view and annotate workorders. The wearable computer will be able to "read aloud" workorders and other task-related documents through speech synthesis. The subsystem will provide voice commands for navigating repair documentation in IETM format in order to give the mechanics greater flexibility in performing the repairs. By using this system, the mechanics will be able to perform repairs while in less-than-ideal environments where they cannot use their hands to access the PEDD. The subsystem will also provide methods for retrieving workorders from a specified source, and for updating the status of workorders.

3.2 Functional Requirements

The repair subsystem must provide speech-based interactive navigation through IETMs and workorders on a wearable computer. This system will facilitate the repair of planes by allowing the repair mechanics to retrieve data in otherwise unfavorable situations, such as when both hands are occupied with a repair.

3.3 Non-Functional Requirements

3.3.1 User Interface and Human Factors

This repair subsystem will be used by F-18 mechanics. There will be a short training session necessary for training the speech recognition software and familiarizing existing mechanics with the system. This training session will probably be integrated with new mechanic training. It is not essential that the mechanics be protected from making errors while using the subsystem, except while they are updating the status of workorders. This will be addressed by explicit confirmation of workorder status changes. The repair subsystem will employ a microphone for gathering speech input and earphones for relaying synthesized speech to the mechanic. These devices will ideally be borrowed from the specialized communication systems currently used in the repair environment.

3.3.2 Documentation

Documentation should be included which covers all use cases of the speech recognition application. Documentation will be available on how to control the synthesized reading of repair documentation, alter a workorder, and search for IETMs. This documentation is targeted at the individual mechanics who will be using the system to perform repairs.

3.3.3 Hardware Considerations

The proposed system is to be used on a networked portable computer. The computer must be powerful enough to run the speech recognition and synthesis software needed by the subsystem. The target for this requirement is a computer with at least a Pentium 166MHz chip with 32Mbytes of memory. The computer must be capable of supporting audio input and output, and must have enough storage space (approximately 0.5 gigabytes) to maintain the speech recognition and synthesis software, as well as some cached workorder and technical manual information. The computer should be shock resistant to 1 meter. The network the computer is connected to must support file transfers of at least 10 Mbits/s.

3.3.4 Performance Characteristics

The system must be capable of a 90% speech recognition rate for common navigational commands, and should be fast enough to recognize normally spoken speech. The response time for common navigational commands will be reasonable; less than 3 seconds for common navigational commands. The system will be able to handle any size IETM that it can store locally.

3.3.5 Error Handling and Extreme Conditions

The user will be presented with a list of valid commands (upon request) at all appropriate times during the repair. Standard techniques (such as TCP/IP) will be used to minimize the likelihood of data loss over the network. If the network becomes unavailable, any pending workorder on the mechanic's portable computer will be saved for future updates upon reconnection of any sort (wireless or direct connection). If the speech system becomes unavailable, all functionality will be able to be duplicated using the visual interface. The speech system will prompt for a repetition if it does not understand the command. The workorders will be available for download from the server while the workorder is in progress, to prevent data loss in the event of a catastrophic failure.

3.3.6 System Interfacing

This system takes IETM input and workorder input from the Lotus Notes database. The repair subsystem uses input from the modeling subsystem to help the mechanic locate the stickies associated with his current repair.

3.3.7 Quality Issues

It is important that the system be portable. The computer must not greatly inhibit the mechanics mobility nor greatly diminish his or her ability to perform repairs in low space environments. Therefore, the wearable computer must be no larger than 200 cubic inches, and fit closely to the body. The system must be able to provide the same (or better) quality of repair data than the paper-based documentation provides. The microphone and speaker system should compensate for the high level of ambient noise.

3.3.8 System Modifications

Updating the system for improved speech recognition may require the introduction of more powerful hardware. A new speech recognition engine may be substituted at a later date.

3.3.9 Physical Environment

The system will exist in various repair environments, with a concentration on the repair environment of an aircraft carrier. This environment will produce large amounts of ambient noise. There is also the possibility of grime permeating the hardware, due to the less-than-pristine quality of the repair area. The system, however, will be location independent. It will require only a network connection to a Lotus Notes database containing workorders and IETMs.

3.3.10 Security Issues

Access to the subsystem must be controlled through an external password system. The mechanics must not be able to edit static information in IETMs in the repair documentation or in workorders.

3.3.11 Resource Issues

The repair subsystem will be maintained by staff to be employed in the future who will have an understanding of the system design and implementation. No repair subsystem specific information will require back ups. The workorders and IETMs will be backed up independently by the Workflow subsystem.

3.4 Constraints

The object and case models will be constructed using Together/J. The source control will be handled using CVS. The subsystem must run under Windows 98. We will require the Java 1.2 Run-Time Environment with the JSAPI extentions.

3.5 System Model

3.5.1 Scenarios

Scenario name: Normal Operation
The Lotus Notes DB informs mechanic Santana that he has a workorder assigned. Mechanic Santana activates his PEDD and connects to workflow database, downloading his workorder and checking which plane the workorder specifies he is to repair. Santana reads over the workorder and figures out the materials and procedures needed. Santana goes to the plane and performs the required procedures. He may update the workorder as he goes along. If one item cannot be done (lack of expertise or the appropriate parts, for example), then he adds an annotation to the workorder to record this, and perhaps orders the part or recommends another mechanic. Mechanic Santana signs off on the workorder and submits it to the Lotus Notes database for approval. The Lotus Notes DB informs the repair supervisor that a workorder is ready for post-repair approval.

Scenario name: GetWorkorder
The Lotus Notes DB notifies Lola, a mechanic, of a workorder that has been pushed to him from the database. Lola accepts the workorder. The workorder is downloaded to Lola's PEDD.

Scenario name: Wireless Network Down
Mechanic Williams' PEDD informs him the wireless network has gone down. Williams realizes he can complete the current repair without additional documentation. After finishing the repair, Williams reports the network condition, and that the repair was completed to his supervisor Barry. Barry informs the system that Williams' repair was completed or Williams connects his PEDD directly to an active segment of the network. Barry decides that assigning Williams another PEDD will not solve the problem. Instead, he assigns Williams directly to a repair he can handle without access to the Lotus Notes database.

Scenario name: Part needed for workorder
ChiChi, a mechanic, begins work on a recently downloaded workorder, but finds that she needs a part that is not currently available. ChiChi annotates the workorder to include a description of the necessary part(s), and resubmits it to the Lotus Notes database.

Scenario name: Mechanic not qualified
A workorder is downloaded to mechanic Donovan's PEDD, but he finds that he is not qualified to handle the work necessary. He annotates the workorder to indicate the correct level of expertise necessary to handle the job, and resubmits it to the Lotus Notes database through the speech system.

3.5.2 Use Case Models

The top level use case illustrates the relationship between the various subsystems. The mechanic interacts with the various systems via the Speech System, or the Visual Display and mouse device on the PEDD. Most of the functionality available through the PEDD will also be available through the speech system.

3.5.2.1 Actors

Mechanic

LotusNotesDB

3.5.2.2 Use Cases

Name: RetrieveWorkorder
Actors: Mechanic, Lotus Notes DB
Entry Conditions:

Workorder open
Mechanic available
Plane accessible

Flow of Events:

Lotus Notes DB notifies mechanic of workorder.
Mechanic denies / accepts the notification, and changes the Workorder status accordingly.
Workorder downloaded to PEDD.

Exit Conditions: Workorder is successfully downloaded.
Exceptions:

Mechanic can't accept the workorder
Connection down

Special Requirements: PEDD must have space to download Workorder

Name: AnnotateWorkorder
Actors: Mechanic, Lotus Notes DB
Entry Condition: Mechanic is working on an active workorder that needs to be edited
Flow of Events:

Mechanic identifies area to be changed (either sticky status or notes section)
Mechanic makes changes in that area on his/her local copy on PEDD
Mechanic submits changes to Lotus Notes DB

Exit Condition: Modified workorder is in Lotus Notes DB
Exception: DB is down, connection is lost
Special Requirements: none

Name: SubmitForApproval
Actors: Mechanic, Lotus Notes DB
Entry Conditions: Mechanic has finished his/her repair
Flow of Events:

Mechanic changes status of workorder to Repaired, Awaiting Approval
Mechanic submits the workorder to the Lotus Notes DB, which will send notification to the inspector for approval.

Exit Conditions: Workorder is in DB awaiting approval and QC inspector has been notified that the repair is done
Exception: DB is down, connection lost
Special Requirements: none

Name: RetrieveIETM
Actors: Mechanic, Lotus Notes database
Entry Conditions:

Mechanic is logged in

Flow of Events:

Mechanic issues a speech command to retrieve a specific IETM from the database.
The speech system interprets that command and passes the result to the PEDD.
The PEDD executes a query for the IETM.
The PEDD receives the IETM from the database.
The PEDD insures that the grammar is set to IETM navigation, and displays the IETM.

Exit Conditions: IETM is displayed.
Exceptions:

Mechanic doesn’t have access to IETM.
IETM doesn’t exist.

Special Requirements: None

3.5.3 Object Models

3.5.3.1 Data Dictionary

Qualification Level is a numerical quantifier for a mechanic's qualification, to determine whether or not they're capable of doing a particular job.
Status is a number corresponding to the status of a particular workorder, whether it is finished or pending further action of some sort.
User Name is the login ID of each mechanic
Network Status is the state that the network is in, represented by a number corresponding to the state.
Plane Reference is an integer that is used to identify a particular F-18 plane.
Notes are the specific annotations made to a workorder or a sticky by mechanics.

3.5.3.2 Class Diagram

Our object diagram consists of 8 objects: PEDD, Workorder, Sticky, IETM, Annotation, Speech package, LotusNotesDB, and User. The workorder is a document, as are IETMs. They implement the Document interface, which is owned by Workflow. Annotations implement the AssociatedDocument Interface from the Workflow subsystem. The PEDD (wearable computer) can have multiple workorders stored on it. A workorder consists of one or more IETMs, one or more stickies, and zero or more annotations. Each workorder can have multiple IETMs while each IETM can be included in more than one workorder. IETMs can also be cached on the PEDD. The Lotus Notes database contains multiple Workorders and Users' (mechanics') data. The Speech package is accessed through the PEDD, which provides methods for recognizing commands, synthesizing text, and changing grammars.

This package is used through the PEDD, and provides methods for recognizing commands, synthesizing text, and changing grammars.

3.5.4 Dynamic Models

AnnotateWorkorder: A mechanic sends a voice command to the Speech System to begin annotation of the current work order by saying "Annotate work order" while viewing the current work order. The annotations are saved on the PEDD, but the changes are not sent to the Lotus Notes database until the work order is submitted. This allows the mechanic add to the annotation at a later time by repeating the Annotate work order command.

ReceiveWorkorder: The Lotus Notes database sends a message that a work order has been assigned to the PEDD of a mechanic. The PEDD displays the message and directs the speech system to change recognition modes. The Speech System then begins reading the work order message. The Mechanic can then use Speech System to request that the PEDD download the workorder. When the workorder is downloaded the PEDD informs the Speech System of the change in interface modes.

SubmitWorkorder: The mechanic sends a voice command to the Speech System to submit the active workorder. The Speech System relays this message to the PEDD, which submits the workorder to the Lotus Notes database.

RetrieveIETM: The mechanic sends a voice command to the Speech System to retrieve a new IETM. The Speech System relays this message to the PEDD, which requests the IETM from the Lotus Notes Database. The database returns the IETM to the PEDD, which initializes the Speech System to navigate the IETM.

3.5.5 User Interface

The following is a tentative layout of the commands available through the speech system for navigation of IETMs and the rest of the workorder system. The visual display of workorders and IETMs will be handled by the Inspection subsystem.

All Modes :

Mode<Documentation viewer> || <workorder viewer>
Up<Number>
Down<Number>
getWorkorder

Mode : Documentation Viewer
Navigation Category:

I/O Category:

Mode: workorder viewer
Navigation Category:

I/O Category: