STARS Requirements Review minutes

Authoring - Jonathan Rosenberg

Current System

• All paper
• Authored by manufactureres and assemblers
• Annotations to IETMs are just memos
• New versions must frequently be issued and distributed to everyone who has the old version.
• This is very expensive.

Proposed System

• Standardized IETMs
• Documents are scanned in and become "Digital Documents" and then are processed into IETMs.
• There is a formal Quality Control system.
• Annotations are done through this system.
• Usable by people who don't know anything about the subjet of the documents being converted.
• Usable by people unfamiliar with the existing process.

Requirements

Core Requirements

• Convert Technical Manuals into IETMs
• Allow for Annotations to the IETMs
• Provide a Quality Control system.

Additional Requirements

• Should be easy to use
• Requires a networked PC capable of running the required software.
• Adequate storage space.
• Version Control
• Modularity
• Reliable and secure network communication

Use Cases

• Digitize Document
• Distribute Scanning Task
• Edit Digital Document
• Edit IETM
• IETM-ize
• Issue Annotation
• Merge IETM
• Verify Digital Document
• Verify IETM
• View IETM

In-depth look at the IETM-ize Use Case

Activity Diagram

Object Model

• Joint effort with Workflow
• We deal only with Documents.
• Workflow owns the Document interface.

The Document Object

Open Issues

• Issue: AIMSS 4.0 and ACS are not compatible.

  Status: Looking for OCR software to replace ACS.

Workflow - Kaushik Merchant

Requirements

Core Requirements

• Documents have access control.
• Access to database can be remote.
• Concurrent access to database should be supported.
• Synchronous/asynchronous notification
• Extensible solution

Optional Requirements

• Document search using arbitrary fields
• Automatically generated work orders

Fancy Requirements

• Automatic maintenance control scheduling
• Plug-and-chug databases

Use cases

SubmitDocument

• Authenticates user and verifies access rights.
• Enters new documents along with associated documents into the workflow database
• Notifies appropriate parties about the new document

UpdateDocument

• Authenticates user and verifies access rights
• Enters updated document along with associated documents into the database
• Older version of the document becomes the previous version of the new one.
• Notifies appropriate parties about the updated document.

1. Bob the Technical Writer edits IETM 1.1 and calls SubmitDocument.
2. Bob is authenticated and his access rights are verified.
3. The updated IETM is stored as IETM 1.2.
4. IETM 1.1 remains in the database and becomes available as the old version of IETM 1.2.
5. Appropriate parties are notified of the update.

Object Model

Open issues and questions

• Issue: Where do we get a list of users to be notified?
  
• Issue: Control of the Document interface: should other teams be able to commit changes to it?
  

• Question(Eric Stein): Is "Consists of" the right association between Documents and AssociatedDocuments? This doesn't seem to give a Document any identity other than the collection of AssociatedDocuments that make it up. Consider a change in terminology.

  Kaushik: We think it's right; aggregation allows the aggregate to be more than the sum of its parts.

• Question(Client): How can one IETM refer to others?

  Kaushik: That's out of Workflow's scope. Within an IETM, it can be anything necessary.

Modeling - Matthew Weyent

• Create model of the airplane and its components
• Develop API for virutally navigating the airplane model
• Provide API for graphically manipulating "Stickies"
• Build a web-based navigation tool

Requirements

Functional Requirements

• Provide navigation methods for navigation through a 3d model of an airplane and its components.
• Provide location information in a 3d coordinate system for the airplane and its components.
• Map locations (x,y,z) to specific parts of the airplane and back.
• Locate Stickies associated with components or the whole airplane
• Provide a GUI and manipulation methods for Stickes in a Sticky database

Nonfunctional Requirements

• UI and Human Factors
  • Web-based user interface
  • Access rights
• Documentation
  • Describe the Web-based navigation tool.
  • Javadoc
  • Other doc available to other subsystems
• Hardware Considerations
  • Large storage space
  • Lots of memory
  • Graphics acceleration is not available
  • Web availability on remote machines
• Performance Characteristics
  • There will be real-time requests and non-real-time requests.
  • Depends on the performance of Java3D
• Error Handling and Extreme Conditions
  • Error Handling: inter-subsystem, dialogue with web user
  • Extreme conditions: low memory, cpu contention.
• System Interface
  • Interface to Augmented Reality, Maintenance/Workflow, and Authoring
• Quality Issues
  • System overload
  • Another subsystem unavailable
  • Accurate output
  • Platform-independent
• System Modifications
  • Extensible so other weapons systems may be used
  • Use of Abstract Factory pattern allows other subsystems to not care about this change.
• Security Issues
  • Each subsystem must limit access to shared memory
  • Data encryption should be used
• Resource Issues
  • No permanent Workflow data
  • Navigation information must be stored

Constraints

• Platform-independence
• Speed of Java
• Together/J

NavigateComponenet Use Case

• Actors: Authoring, AR, RemoteUser
• Entry: Actor wants to view/manipulate model
• Flow of Events
  1. Request entry of system if not already in
  2. Call method to use for model manipulation
  3. Exit system if done
• Exit: Actor is done manipulating the model
• Special Requirements: Is the system on the local machine? Speed?

Open Issues

• Issue: Can complexity be reduced if it doesn't run on a wearable computer?

Inspection - Zeb Drivdahl

The team website is at http://www.contrib.andrew.cmu.edu/~drivdahl/sepage/inspect.htm for now.

The Inspection Subsystem will simplify and streamline the inspection process for maintenance personnel as well as modernize the inspection process through the use of IETMs instead of paper manuals.

Requirements

Core Requirements

• Ability to downlaod and interact with IETM based workorders for inspection tasks
• Placement of virtual stickies
• Upload virtual stickies to maintenance system
• Capacity to operate in adverse conditions.

Optional Requirements

• Use of PEDD or HMD
• Non standard, easy to use input device

Fancy Requirements

• Wireless connection to the maintenance system and the AR model.
• Use of data glove pointing device

An "A Day In the Life Of" Scenario

• logs in and downloads the day's workorders
• calibrates equipment
• logs out in order to begin actual inspections
• arrives at plane
• follows workorder, recording discrepancies
• returns to maintenance depot
• sends stickies and workorders to maintenance system.

Boundaries of Inspection System

• Concerned primarily with placement and recording of virtual stickies and the display of workorders
• Determination of location is handled by AR
• Display of airplane model information is the concern of AR
• Speech recognition and synthesis technologies are handled by the Repair team.

Open issues and questions

• Issue: Workorders:

  • How are they created?
  • How are they related to stickies?
  • What is their lifetime?

  Status: These should be dealt with by the new Workorder team.

• Issue: How are stickies placed?

  Status: Handled by AR and Modeling teams; the main interaction for the Inspection team is through AR.

• Question: What are IETM-based workorders?

  Answer: Workorders should have references to parts of IETMs so they can be pulled up during inspection.

• Question: What is the "standard Inspection Process?"?

  Answer: The workorder will explain what to do.
  Stickies will be placed to create new workorders.

• Question: How are IETMs going to be used in the Inspection process?

  Answer: Se the answer to "What are IETM-based workorders?"

• (Issue)Question: How will IETMs be navigated?

  Answer: Open Issue.

• Issue: Still don't know the details on PEDD/HMD hardware.

Repair - Pat Larkin

Current System

• Paper-based. Paper documents are hard to search. It is expensive and not dynamic, though the interface is simple and familiar.
• Jobs are assigned manually. This is flexible.
• Paper is flammable

Proposed System

• Speech-based IETM and Workorder navigation provides a "hands-off" interface
• Allows annotating documents while doing repair or inspection.
• The system should be able to handle any future scheduling process.
• Documents can easily be searched
• The PDA will not be flammable.

Annotate Workorder Use Case

• 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 or connection is lost.
• Special Requirements: none.

Retrieve IETM Use Case

• Actors: Mechanic, Lotus Notes database
• Entry Condition: Mechanic is logged in
• Flow of Events:
  • Mechanic issues a speech command to retrievea 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 recieves the IETM from the database.
  • The PEDD ensures that the grammer is set to IETM navigation , and displays the IETM.
• Exit Condition: IETM is displayed.
• Exceptions:
  • Mechanic doesn't have access to the IETM requested.
  • The IETM doesn't exist.
• Special Requirements: None.

Requirements

• Speech-based IETM and Workorder navigation (speech recognition and synthesis)
• Speech Recognition requires user training, a 90% recognition rate, and a 3 second maximum latency.
• IETM and Workorder retrieval and notification abilities
• Network connectivity
• Appropriate hardware
• Java 1.2 with JSAPI extensions

Open issues and questions

• Issue: The Notification interface is not well-defined.

  The system currently in use by the Navy is manual notification. In the worst case, they can continue this system.

• Issue: Current free-form speech recognition systems do poorly on open-ended vocabularies.
• Issue: IETMs are large.
• Issue: Authentication standards haven't been established.

• Question: What are the CPU&storage limits on a PEDD?

  Answer: Pentium 166 with 32Megs are required for speech recognition.

• Question: Your presentation referenced a "Submit" interface to the Workflow subsystem. Note that this is distinct from "Update"; you probably mean the latter.

  Answer: Ok.

• Question: Is the network needed during the action of repairing the plane?

  Answer: Not for any core functionality, but it would allow us to update workorders and such during the work, which may be interesting.

• Question: Given an IETM, how do you generate speech?

  Answer: A text-to-speech system.

• Question: Can this speech synthesis system parse SGML?

  Answer: No, that'll have to be done outside of the speech system.

• (Issue) Question: How can the repairer use a PEDD to lookup part of an IETM using only voice input, if there are many levels to an IETM?

  Answer: We currently assume that the worker has enough knowledge of the IETM to request the section by exact name. We could provide a way to search for a section.

• Question: Who's doing the IETM interface? (Authoring or Repair)?

  Answer: Repair will call Authoring's interface for this.

• Question: Where'd you get the milk graphic?

  Answer: Somewhere on Microsoft's page.

• Question: If you're displaying the workorder and/or IETM on the screen, why do speech as well?

  Answer: It can be hard to look at the display - even a head-mounted display - while working.

Project Management(Architecture) - Dan Heller

Subsystem Decomposition

• STARS is a closed architecture.
• The architecture is both layered and partitioned.
• There are new UI and Workorder teams which are not in the diagram yet.

Project Communication

• Lotus Notes is used for communication
• Architecture liasons discuss inter-team issues
• Teams have liasons directly to other teams.
• UI and Workorder are classified as Cross team groups.

Project Deliverables

Project Phases

Group Roles

Open issues and questions

• (Issue) Question: The subsystem decomposition doesn't look right. For example, I think the Inspection and Repair subsystems want to talk directly to eachother.

  Answer: Could be. We'll look into it at the Architecture meeting.

Augmented Reality - Jeremy Jones

Current System

Proposed System

Scenario

Requirements

Functional Requirements

• Mange the Head Mounted Display
• Calibration of the wire-frame display
• Interpret low-level data from input devices
• Dispatch events to other system

Nonfunctional requirements

• Hardware Considerations
  • PEDD must be able to run a JVM
  • If the PEDD is running Win98, OpenGL or DirectX are needed to implement Java3D.
  • The positioning device must be accurate to within 3 inches.
  • The orientation device must be sensitive enough to track head movement.
• Performance Characteristics
  • Frame rate must be great enough that wire-frame updates are smooth.
  • Input devices must provide their signal quickly enough that the system can respond accurately.
• Error Handling and Extreme Conditions
  • Make sure that the data is valid. I.e., don't send the Modeling subsystem coordinates that are far away from the model.
  • When it is determined that the positioning or orientation is wrong, prompt the user to recalibrate.
  • No information is lost if the PEDD fails; the only thing that didn't come from Workflow is the calibration, which needs to be redone.
• System Interfacing
  
  • The Augmented Reality subsystem interacts with the Maintenance and Modeling subsystems.
• System Modification
  • New hardware will require new drivers and events to be added.
  • As technology changes, the user interface may need to change.
  • Calibration may become automated with new technology
• Security Issues
  • Augmented Reality itself has no risk of attack, as it has no persistant data and no transmissions to external systems.
  • Subsystems which contain protected data will need to do something about it.

Class diagram

Q&A

• (Issue) Question(Bill): The unique id's for document id's: are they owned by Workflow or Authoring?

  (No Answer)

• Question(Bill): Is there some sort of handle to get the document from Workflow?

  Answer(Kaushik): Yes.

• Question: Authentication - is it inter-subsystem?

  Answer(Kaushik): No.

• Question: Where is the model stored?

  Answers:

  • Matt: Some database somewhere.
  • Kaushik: It could easily be put into workflow.

• Question: IETMs can be viewed with what program?
  

  Answer: IETMs are SGML documents; they can be viewed with any SGML viewer.

• (Issue) Question: How big will the IETM-viewr be?

  Answer: Framemaker-ish. Authoring will come up with a more specific answer.

• Question: Workflow, re: robustnes: What happens when asynchronous notification is requested byt "the subsystem" is down?

  Answer: Kaushik: It should eventually time out and notify someone else.

• Question: How about concurrent updates?

  Answer: Kaushik: Not allowed.

• (Issue) Question: Will the system notice when a subsystem is down and notify someone?

  Answer: No answer at this time.

• (Issue) Question: Synchronous notification: pager v. wearable computer. If wearable, the system needs to know who's loggged in to each computer, which is something that hasn't been addressed. I.e., all other authentication issues have been resolved by required authentication to happen for each transaction, but this requires something to keep track.
  

  Answer: No answer at this time.
  

• Question (for Augmented Reality): What's the Timer object for?

  Answer: Just for updating the display.

  (Issue) Question (for Augmented Reality): You know Java's got a Timer?

  Answer: We haven't looked into that yet.

• Question (for Augmented Reality): How are you anticipating that the memory on the PEDD will be divided between the systems?

  Answer: The PEDD has 128 megabytes of RAM. We anticipate Modeling using 64, subsystem [ed: didn't catch it] using 32, and splitting the rest up among the other subsystems.

• Question (for Augmented Reality): Who is doing IETM viewing?

  Answer: Inspection or Repair.

• Question: How much network bandwidth is needed?

  Answer: As fast as possible. There probably won't be more than 10bT available.

• Question: Will there be a read-ahead cache (i.e., downloading the next page of an IETM while viewing the current one.)

  Answer: We plan to have all needed parts of the IETM cached on disk before the repair is begun.

  Another Semantic point: The client was somewhat insistant that "IETMs don't have "pages".".

  Answer: Ok, we'll use the concepts of "screens" or "sections" instead.

• Question: What's the actual structure of an IETM?

  Answer: It's fairly involved. Someone from Authoring will post a link that the clients gave us.

• Update from Authoring: because of conversations with the client, we've decided to store IETMs in the database in sections, not as single entities.