3.5.2.1 Actors
- Inspector
- Workflow subsystem
- Augmented Reality subsystem
3.5.2.2 Use Cases
15-413 Software Engineering
Fall 1999
Carnegie Mellon University
Pittsburgh, PA 15213
Version R0.1 09/15/98 Robin Loh. Created
Version R0.2 09/14/98 Joyce Johnstone. revised template
Version R0.2 10/06/99 Nathan Bingham. added specific information from Inspection Subsystem
Preface:
This document addresses the requirements 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:
Inspection Subsystem
Nathan Bingham
Zeb Drivdahl
Richard Ekwall
Robert Kurian
Alexander Kutner
Tracy Wortham
The purpose of the inspection system is to give aircraft inspectors
an easy way to perform an IETM based inspection on an aircraft and log
any discrepancies found in to the STARS system. The goal is to provide
the inspectors with a system that displays IETMs for them and has a simple,
intuitive method of logging discrepancies encountered in to the STARS system
via a data glove / GPS bracelet pointing system. The inspection subsystem
seeks to streamline the inspection process and simplify the job of the
aircraft inspector.
Currently, inspections are performed using either paper based technical
manuals or an IETM check list and a two-dimensional image of the aircraft
being inspected. Many times the location of discrepancies is identified
by marking the surface with a grease pen or noting distances from physical
aircraft references on a two-dimensional image, e.g., structural frame
and rivets. The result of an IETM-based inspection is a listing of discrepancies
that are assigned as repair tasks in work orders for technicians to correct
them.
3.1 Overview
The inspection subsystem should provide the capability to do an inspection
based on IETM documents. The mechanic will be able to navigate through
the IETM, following its instructions, and add an annotation ("virtual
sticky") to a repair location when a discrepancy is discovered. This
will be done by pointing to a specific location at the airplane, indicating
the discovered discrepancy and the type of repair. These stickies need
to interact with a three-dimensional model of the aircraft and a method
of pointing to a discrepancy that marks the location and description of
the discrepancy on the exact location where the descrepancy was discovered.
3.2 Functional Requirements
3.3 Nonfunctional Requirements
Only trained mechanics will be allowed to use the system. Trained means someone with knowledge of the system, how to use it, and the ability to teach it to someone else. This knowledge will have to occur in some sort of formal training program provided either during basic training for new recruits school or a training workshop for existing personnel. The STARS inspection subsystem should remain simple and straight forward to keep it as an asset instead of a drawback to the people using it. Both inspection personnel and repair personnel will be using the system described in this document, although both fall under the more general category of maintenance personnel (this report is more geared towards inspection personnel).
The majority of user errors will be eliminated by keeping most of the interface based on buttons that allow only well controlled access to the system. The textual element of reported discrepancies (inspector notes) should not pose a problem for the system to process since it exists only as a memo, intended to be seen by other humans and is of no consequence to the data processing elements of the system (this field is meant as a place for any information that may be of use to further inspection or repair personnel but does not fall under any of the normal fields in a discrepancy report). It is still possible for the user to reach an undesired area of the interface or input wrong values but cancel and undo features should be able to save the user.
The input/output devices to the system that will be used by the inspector are the PEDD and some sort of positioning device, most likely some sort of GPS bracelet or similar precise location device. More input devices, most notably to the maintenance subsystem where workorders are retrieved from, will be necessary and will be documented as their specifications become clear.
Documentation of the system will consist of three basic document sets:
The system provided by the Insection Team should run on a wearable computer.
The platform will be a P233 MMX with a 340 MB HD, an 800x600 SVGA HMD,
a joypad pointing device, and 2 hours of battery life. It will be running
Windows 98. Some kind of positioning device (i.e. dataglove, "GPS-bracelet")
will have to be connected to the computer to provide the location of stickies
to be placed. There should also be a login procedure, as well as a download
and upload procedures for the workorders. This part of the software system
will probably be shared between the maintenance computer (probably a high-end
server or work-station) and the wearable one.
The wearable computer should have the computational power and the storage
capacity of a low-end desktop computer. Neither the computational power
nor the storage capacity should be a problem though, although the size
of the IETMs might become an issue if a large quantity of them are relevant
to the inspection and need to be stored on the local hard drive. The positioning
device should have an accuracy of about 3 to 4 inches, so that stickies
can be placed at least as accurately as the current system (component name
based or with (x,y) frame locations, eventually grease pencil marked).
The issues concerning the positioning system, should however be taken care
of by the Augmented Reality subsystem. The Inspection Team will only need
to make API calls to read the current position.
The software will be written in Java, with no specific restrictions. The
wearable computer should therefore be able to run full Java.
The inspection interface on the wearable computer should be fast enough
to let the inspector perform his job without being slowed down because
of computational issues. This means that it should not take more than 5
seconds to perform any of the basic operations assosciated with the inspecation
system such as opening and displaying an IETM, changing to the wireframe
view of the plane or back to the inspection view, saving a sticky once
its attributes are known, or displaying anything that could be relevant
in the context of a discrepancy report (for example a sticky information
form to fill in). The positioning system should also be fast enough to
provide a sufficient ease-of-use to the inspector.
The information communication between the maintenance computer and the
wearable computer before and after the inspection should be fast. All information
should be downloaded or uploaded within a few minutes. This represents
an as yet undetermined amount of data, and speed will depend on which transfer
mode is being used (Ethernet, USB, Serial, Parallel...).
3.3.5.1 Error Handling
The user input available to the inspector in our subsystem is limited
to error free input since it will be menu driven. Any possible way the
inspector can give feedback into the system will be caught, and only pertinent
information will be accepted (i.e. if the inspector pushes a button that
doesn't mean something in the stage he is in, then the button will be ignored).
This will drastically reduce user error, but of course precautions still
have to be taken. In the event of some data being entered incorrectly (through
some malfunction invalid input might be entered), the inspector should
be able to go back to the previous menu and change the last selection.
3.3.5.2 Extreme Conditions
The design must be prepared for extreme situations. The following are examples
of possible adverse conditions and how the system should deal with them.
This system is primarily standalone. It interfaces with an authentication subsystem (located on the maintenance computer) to authenticate the inspector before the start of the inspection. The inspection itself is performed totally offline (with the possible exception of the positioning system which is available for the whole time of the inspection). The wearable computer will be connected to the maintenance computer only when uploading or downloading stickies, workorders, IETMs and any other document relevant to the inspection or to the inspection report. This information exchange should be done via a LAN, USB, Serial or Parallel bus, or perhaps even some form of wireless connection. The positioning system will be attached to the wearable computer at all times and will provide the necessary information for the location of stickies.
The system must be reliable in that it must allow the inspectors to traverse through the correct workorder information. The system must provide the inspector with the ability to report a discrepancy and then correctly store this information in the form of a sticky. The system response time for a user request should take no longer than 5 seconds. The system must recognize when certain components that it relies on are down. If another system is down, the user must be notified. The component of the system which navigates through workorders and allows for discrepancies to be reported must be able to run on a PEDD.
The design of the subsystem should be fairly pliable. It should be based on objects which are dynamic and can vary in different scenarios; for example, a sticky can be placed anywhere and there are no limits on the sticky except that it should be placed on the wire frame model. The wire frame model, then, should be an editable object, thereby making the location of the sticky unrestricted. The only hindrance in this design could be the menu driven quality. As mentioned in Section 3.3.5, menu driven design models have the advantage of disallowing user error, but this would be done at the cost of being limited to the menu options. It is possible that more menu options will be found to be desirable.
New designs in planes and anything the inspector has the duty of inspecting
are unpredictable elements; if a new plane design can not be inspected
using the equipment selected, then the concepts of this equipment could
be ported to a new set of equipment designed with the new plane in mind.
Currently the best that can be done is to make the initial equipment as
adaptable to any situation as possible, which includes making the size
and weight of any wearable components as minimal as possible so as to avoid
movement hindrance. This should be done without sacrificing necessary features
of the subsystem. Still, new features such as new menus or a new type of
interface could be required in the future.
The target equipment of the majority of this system is the PEDD. There may be several PEDDs in use at the same time. The PEDDs must be able to function in the harsh electromagnetic environment of an aircraft hanger. As previously mentioned, the PEDDs and HMDs must also be able to function in the presence of harsh weather, dirty working conditions and other extremes. Refer to section 3.3.5.2 for a more detailed description of the physical environment and adverse conditions the equipment must be able to operate under.
Access should be controlled in the sense that the inspector's work should maintain a level of confidentiality. In order to ensure that this equipment can be used to inspect any level or classification of plane, including perhaps some type of plane whose status is classified, any data contained within this subsystem should be available only to the inspector as long as it is contained within this subsystem. The best way to make sure this happens is to rely on software security methods to protect the data. Wireless communication should be limited in this system, reducing one potential security problem. In the case of some sort of power outage or power supply failure, the system could become a security risk. During any saving of information to disk, the information should be encrypted to avoid unclassified personnel from reading the data. Locally to the inspector subsystem this is most of what the subsystem can handle. It would be be the inspector's responsibility not to leave the equipment unattended, and to double check the information given at the end of inspection to make sure that it is accurate. The subsystem should have the responsibility to protect itself as much as it can, and it would be limited in its facility to do this and to allow the inspector to have full capabilities and access to all pertinent data at all times (which is necessary for the job).
Note that this information is only covering the inspection subsystem,
where the "inspection subsystem" is defined as the time in which
inspection tools are utilized in analyzing an object and placing stickies
on it relating information about repairs to be made. It does not cover
security of the system that these stickies will be given to, nor the security
of the system that initially uploads the job to be done.
The content stored on the wearable computer is temporary, since it will
be uploaded at the start and be more or less "cleaned-up" at
the end of an inspection. This means that the wearable computer will not
need an intensive backup program. However, a backup of all workorders should
be present in a database on the maintenance computer. This backup can be
made at the beginning of every inspection, before anything is downloaded
to the wearable computer. Some form of archive should also be present on
the maintenance computer to store old workorders and stickies associated
with the inspection. This archiving and backup is not a significant issue
for the Inspection Team, since it will not directly affect the inspection
itself.
System installation and maintenance will most likely be provided by some
member(s) of the STARS project. This issue has yet to be resolved and more
discussion is necessary to resolve the issue.
The system will be developed using Java. Object and case models will be constructed using the CASE tool TogetherJ. Version control of the source code will be handled using CVS.
Jack Smith, an inspector for the navy, shows up to work a little bit late and rushes over to the equipment closet to snag his wearable computer and the attendant on duty checks one out to him. Jack then heads over to the maintenance server and when he gets there, logs into the system by submitting his username and password and the system asks him to plug the wearable into the server's data outlet. When he has done so, the server uploads Jack's orders into his wearable computer and Jack logs out of the system. Jack sees on his head-mounted display that he is supposed to do a quality control inspection of an engine repair recently performed on an F-18 in the lower deck and he follows the directions to the plane. He switches the view on his head-mounted display to the wireframe overlay of the physical plane and the sticky related to the engine repair is brightly visible. Having found the exact location in question, Jack switches the view on his head-mounted display back to the orders, which include step-by-step instructions (in the form of an IETM), of how to check that the repair was done satisfactorily.Using simple buttons on his arm, Jack steps through the directions, checking each item as indicated, and finds that the repair was done well.Seeing no need to have any further repairs performed on this area, he changes the status of the sticky to 'complete' in his wearable and heads back to the maintenance server.After logging in again, he plugs his wearable into the server and uploads the results of his inspection. The server, seeing that it is Jack's lunchtime, notifies him that he has an hour break and should report back at that time.
Airman Doe has just performed a 14-day periodic corrosion inspection. He has noticed that the left wing has rust spots. These spots have been saved in his PEDD as virtual "sticky notes" and he now returns to the main terminal to download them to the main repair and workflow system. He is prompted for a password, which he enters. He connects his PEDD to the terminal via a network cable and waits for the system to authorize the download of the stickies. John Doe then looks at the screen where the workorder he was assigned is displayed and downloads the stickies containing the anomalies found during the inspection. The maintenance system confirms the download of the stickies and generates the information later necessary for the repair of the anomalies. Airman Doe finishes his inspection by logging out from the maintenance system and heads off for a cup of coffee.
Iggy Bjornsonyk, inspector on an aircraft carrier somewhere in the Mediterranean Sea, performs a 14-day periodic rust inspection. He discovers rust spots on the right wing of the airplane. On his PEDD, he activates the discrepancy mode and is presented with a form, asking for all the data relevant to the anomaly. This form later generates the sticky notes associated with the rust spots. The first field contains the location of the anomaly. The current location of Joe's dataglove is displayed in his HMD. When he points on the rust with his digital finger, the coordinates of the fingertip are automatically entered in the location field. Airman Inspectson now has to identify the nature of the discrepancy. He has already identified it as rust, and selects the corresponding option in a short list. The third step of the report involves identifying the severity of what the inspector has just found. Considering that the rust spots seem very superficial and that the wing still holds to the plane, Joe classifies this discrepancy as minor. Once again, he selects this option from a list displayed in his HMD. Inspector Joe is satisfied with his report. Nothing needs to be cancelled or altered. The last field of the form is called "notes", but since the discrepancy is pretty standard and well known, Joe decides he doesn't need to fill this field. Instead, he confirms the report, which is stored in his wearable computer. The discrepancy is logged and a confirmation message appears in Inspectson's HMD. Joe continues his inspection, stepping forward to the next task in his workorder.
Inspector John J. Johnson logs into the maintenance computer to find what exciting tasks he has awaiting for him today. He finds that he will have to perform a quality control inspection on one of the planes that recently had a wing repaired. He downloads all of the related information into his PEDD, dons his head mounted display and dataglove, and is off to the plane. Once at the plane, he calibrates his glove and display, and sees the wing in question while in his special wireframe mode. At first glance it seems the wing might be all right, but then he notices that the repairman apparently thought Elmer's glue could serve as sufficient sealant for the cracks that were originally noted on the wing. That won't do. Luckily the maintenance computer has all of the repairman's information stored, so he can be held accountable for his foolhardy actions. Using a cleverly designed interface, he inputs his findings into his PEDD as a new sticky. Inspector John, Johnson that is, heads back to the maintenance computer and uploads the new sticky's information from the PEDD. His task completed, he logs off the computer and heads for the head.
Mark arrives at work and checks out a wearable computer.He logs into the maintenance computer to see which tasks have been assigned to him. Two work orders for scheduled inspections are waiting for him. Mark downloads the related information to his PEDD by plugging the wearable computer into the maintenance computer. Mark logs out of the system.He walks to the aircraft and calibrates the dataglove and the head mounted display. Inspector Mark begins reading IETM instructions for the first work order from his head mounted display and looks over each part of the aircraft on the inspection list. Mark finishes the tasks in the first work order and does not find any discrepancies. He continues with the next work order. He checks the aircraft by following the IETM instructions in the second work order and finds no discrepancies.Inspector Mark returns to the maintenance computer, logs in, indicates that he is done with his assigned tasks, and logs out.
3.5.2.1 Actors
- Inspector
- Workflow subsystem
- Augmented Reality subsystem
3.5.2.2 Use Cases
Exit Condition: Successfully checks out for inspection
Special Requirements: None
Exit Condition: Completed inspection orders
Special Requirements: None
Exit Condition: Discrepancy is logged successfully
Special Requirements: Ability to cancel reporting
Exit Condition: Inspector successfully logged out from maintenance system
Special Requirements: None
One PEDD Device may contain many work orders since an inspector may
have more than one work order waiting for him. The work orders are downloaded
from the maintenance computer. A work order may contain more than one sticky
if several repairs need to be made in different locations on the plane.
Once the work orders are downloaded, the inspector will take the PEDD,
which exchanges information with the Inspection and AR System interfaces.
The StickyPlacer may generate many stickies since multiple discrepancies
may be found during an inspection. So the PEDD Device would need to store
many stickies. One sticky may be associated with several work orders because
more than one repair or inspection may be required to correct the found
discrepancy. In that event, the sticky would not be considered resolved/closed
until all workorders associated with it are completed.
There is one StickyPlacer for the AR System Interface (local to the PEDD).
There may be multiple PEDD Devices using the maintenance system interface
since more than one inspector is able to work at the same time.
Initialize
Perform Inspection
Report Discrepancy
Finalize
The user interface for Inspection contains screen shots of both posting
a sticky and of walking through an IETM. The movement from one of these
screens to the other should be obvious given the buttons included.
