1. Introduction | |||
With the increasing complexity of systems such as airplanes or power
plants, access to maintenance procedures at the place of work is essential.
Current maintenance procedures for these systems are costly and inefficient.
Information quickly becomes out-of-date and maintenance manuals are often only available as hardcopy or on workstations far away from the airplane or automobile. In addition, the maintenance information is not tailored to the actual work order, requiring the engineer to perform unnecessary steps before viewing the information that is actually needed to perform the repair. The scope of the STARS project is to cover both the conversion of paper technical manuals to Interactive Electronic Technical Manuals (IETM), as well as the use of IETMs in the field for onsite inspection and repair. The STARS3 work package focuses on the onsite inspection and repair area. Currently, Original Equipment Manufacturers (OEMs) of subsystem components provide IETM-documentation for their products to the system manufacturer for conversion, if needed, and inclusion into their system's overall IETM-documents. An example is the documentation provided by an engine supplier to an aircraft manufacturer. This method of IETM development and management is usually very expensive because the OEM may use different or less effective authoring tools and processes and additional overhead costs of the system manufacture are typically added to those already charged by the OEM. A new way is to distribute the IETM development and maintenance process
across the OEMs, third party IETM authoring organizations, and system manufacturer,
and transfer the IETM products directly to a central database (CDB) of
the system's end user (e.g., the organization flying and maintaining the
aircraft).
Currently, inspections are performed using an IETM check list and a two-dimensional image of the system 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 IETMs need to interact with a three-dimensional model of the system and a way of pointing to a descrepancy that marks the location and description of the discrepancy on a virtual "space sticky" attached exactly to the location where the descrepancy was discovered. |
|||
2. Actors | |||
2.1. DeviceProvider | |||
Description: | |||
DeviceProvider send new IETMPackage to IETM maitainer and give UT:Help to him. | |||
Initiated User Tasks: | |||
No user tasks specified. | |||
2.2. IETM Maintainer | |||
Description: | |||
IETM Maintainers are responsible for maintaining the content of the IETMs used by the technicians during work orders. | |||
Initiated User Tasks: | |||
Upgrade IETM | |||
2.3. Remote Expert | |||
Description: | |||
Remote Experts are available to support Technicians during maintenance or repair procedures. | |||
Initiated User Tasks: | |||
No user tasks specified. | |||
Participating User Tasks: | |||
Request Remote Expert Help | |||
2.4. ServiceTeam | |||
Description: | |||
ServiceTeam is the interface between technical Team and client. f.g They can send feedback from client to A:IETM Maintainer, to give him new idea, how to UT:Upgrade IETM. | |||
Initiated User Tasks: | |||
No user tasks specified. | |||
2.5. Supervisor | |||
Description: | |||
Supervisors monitor technicians during the execution of a procedures. The role of this actor is to make sure procedures are correctly executed and to coordinate any remote expert UT:Help. | |||
Initiated User Tasks: | |||
Initiate Work Order | |||
Participating User Tasks: | |||
Execute Work Order | |||
Instances: | |||
Mr. Smithers | |||
2.6. Technician | |||
Description: | |||
Technicians are responsible for carrying out repairs and maintainenance procedures. | |||
Initiated User Tasks: | |||
Execute Work Order
Find Location & Resources Help Request Data-IS Request Remote Expert Help Use-Ethernet-IS |
|||
Participating User Tasks: | |||
Help
Initiate Work Order |
|||
Instances: | |||
Homer | |||
3. Needs | |||
3.1. Execute Work Order | |||
Initiating Actor: | |||
Technician | |||
Participating Actors: | |||
Supervisor | |||
Flow of Events: | |||
The technician
executes a work order following a flow diagram. The supervisor
monitors the steps accomplished and documented by the technician.
Note: This user task should be refined into use cases by the user interface team. |
|||
Nonfunctional Constraints: | |||
Robustness-Unreliable network service for technician | |||
Use Cases: | |||
Abort-Prefetching-IS
Execute Work Order UC InputValue NoSuperVisConnection Notify Supervisor SelectWorkOrder acknowledgeWorkstep getGeneralInfo show Workflow |
|||
3.2. Find Location & Resources | |||
Initiating Actor: | |||
Technician | |||
Flow of Events: | |||
The technician
requests assistance to find a resource or a location.
Note: This user task should be refined into use cases by the Infoservice team. The resulting use cases should include location tracking of the technician such that the system can provide real time directions. |
|||
Nonfunctional Constraints: | |||
Robustness-Unreliable network service for technician | |||
Use Cases: | |||
Enter-room-IS
FindWay GetCurrentPositionOfTechnician GetTargetPosition Read-IS-Client-Status |
|||
3.3. Help | |||
Initiating Actor: | |||
Technician | |||
Participating Actors: | |||
Technician | |||
Flow of Events: | |||
1.An IETM viewer,who can be an A:IETM
Maintainer, A:Technician
oder service team, doesn't anderstand anything. Then, he clicks the HELP
button on the tool bar.
2.The system responses with showing two new functional buttons "IETMGuideline" and "IETMMessage'". 3. He clicks the "IETMGuideline" button to read the online document. But he is puzzled of something too. 4. He decides to ask help from the expert. Then, he activates the "IETMMessage" Function. The system responses by schowing a list of experts' correspondence address and related informations. 5. He chooses a proper person and sends a message to him. After that, he exits the HELP window. |
|||
Preconditions: | |||
Before that, he must enter the UC:OpenIETM window. | |||
Use Cases: | |||
No use cases specified. | |||
3.4. Initiate Work Order | |||
Initiating Actor: | |||
Supervisor | |||
Participating Actors: | |||
Technician | |||
Flow of Events: | |||
The supervisor
creates a work order and assigns it to a technician.
The technician
is notified and carries out the work order.
Note: This user task should be refined into use cases by the IETM team. It should include all the use cases necessary for a supervisor to create a work order and to notify a technicial to execute it. |
|||
Use Cases: | |||
Workorder-based-Prefetch-IS
assign work order to technician create work order manage work order notify technician |
|||
Open Questions: | |||
workorder-priority available | |||
3.5. Request Data-IS | |||
Initiating Actor: | |||
Technician | |||
Flow of Events: | |||
1) A A:Technician
wants to see a particular
GE:Data-IS d1. He uses the GE:Mobile-GUI-IS to request this document (clicking on a link, typing an url) 2) GE:Mobile-GUI-IS sends the request for the GE:Data-IS d1 to the S:IS-Client. 3.1) GE:Mobile-GUI-IS waits for response from S:IS-Client. 3.2) S:IS-Client receives the request for document d1. 3.3) S:IS-Client checks whether d1 is already in the GE:Cache-IS. 3.4.1) if yes, then d1 is taken from the GE:Cache-IS and sent back to the GE:Mobile-GUI-IS. 3.4.2) otherwise, d1 is requested from the S:IS-Server and saved in the GE:Cache-IS. 4) GE:Mobile-GUI-IS receives GE:Data-IS d1 from S:IS-Client. |
|||
Preconditions: | |||
Connection to between S:IS-Client and an S:IS-Server is established. | |||
Use Cases: | |||
Request-based-Prefetch-IS | |||
3.6. Request Remote Expert Help | |||
Initiating Actor: | |||
Technician | |||
Participating Actors: | |||
Remote Expert | |||
Flow of Events: | |||
The technician
requests UT:Help
from a remote
expert. The remote
expert provides advice and direction to the technician
for unexpected problems.
Note: This is the STARS2 scenario. This will be revised sometimes in the future by the instructors/coaches to complete the specification. |
|||
Use Cases: | |||
No use cases specified. | |||
3.7. Upgrade IETM | |||
Initiating Actor: | |||
IETM Maintainer | |||
Flow of Events: | |||
The IETM
Maintainer releases a new version of an IETM. Thereafter, new work
orders make use of the new version. Ongoing work orders make use of the
older version.
Note: This user task should be refined into use cases by the IETM team. The resulting use cases should explain the steps to setup an IETM such that it can be used during the Initiate Work Order user task. |
|||
Use Cases: | |||
CommitIETM
ConnectionDown EditIETM InstallPackage NotifyIETM OpenIETM |
|||
3.8. Use-Ethernet-IS | |||
Initiating Actor: | |||
Technician | |||
Flow of Events: | |||
1) A:Technician
plugs his Mobile Computer into
an Ethernet socket. 2) S:IS-Client automatically detects that Ethernet is available. 3) A connection via Ethernet between the S:IS-Client and the S:IS-Server is established. |
|||
Preconditions: | |||
Mobile Computer is not yet plugged into an Ethernet socket. | |||
Use Cases: | |||
No use cases specified. | |||
4. Interactions | |||
4.1. Abort-Prefetching-IS | |||
Realized User Task: | |||
Execute Work Order | |||
Flow of events: | |||
1) A A:Technician
wants that the current Prefetch method is stopped. He uses the GE:Mobile-GUI-IS
to give a Prefetching-Abortion-Command.
2) The S:IS-Client is notified about this and stops downloading any GE:Data-IS from the S:IS-Server . |
|||
Services: | |||
No services specified. | |||
4.2. CommitIETM | |||
Realized User Task: | |||
Upgrade IETM | |||
Flow of events: | |||
1. The syntax of the IETM files is checked. Any errors are
reported to the A:IETM
Maintainer.
2. Then all references are checked to lead to existing files, even outside links can be checked by accessing the IETMDB. 3. All locally changed files are send to the IETMDB. |
|||
Preconditions: | |||
The A:IETM Maintainer confirms installation of an package or after presses "commit IETM" while in UC:NotifyIETM use case. | |||
Exit conditions: | |||
New version of the IETM is saved properly to the IETMDB. | |||
Exceptions: | |||
All errors during syntax and reference checking are reported
to the A:IETM
Maintainer and the commitIETM use case is exited.
Also a UC:ConnectionDown exception can appear. |
|||
Nonfunctional Constraints: | |||
IETM Update-Executing work orders | |||
Services: | |||
No services specified. | |||
4.3. ConnectionDown | |||
Realized User Task: | |||
Upgrade IETM | |||
Flow of events: | |||
1. The network connection between the actors is lost. For
instance, the circuit is short oder open.
2. The interruption is found, when the actors want to communicate. 3. The A:Technician reparied it. |
|||
Preconditions: | |||
This use case extends the UC:OpenIETM and UC:NotifyIETM use cases. It is initiated by the system whenever the network connection between the actors is lost. | |||
Exit conditions: | |||
The interruption is cleared. | |||
Nonfunctional Constraints: | |||
IETM Update-Executing work orders | |||
Services: | |||
No services specified. | |||
4.4. Continue-Prefetching-IS | |||
Realized User Task: | |||
No user task specified. | |||
Flow of events: | |||
The Prefetch method which has been interrupted before is continued. | |||
Preconditions: | |||
Prefetching is interrupted. | |||
Services: | |||
No services specified. | |||
4.5. EditIETM | |||
Realized User Task: | |||
Upgrade IETM | |||
Flow of events: | |||
1.The A:IETM
Maintainer invokes UC:EditIETM
function. A menu of all kinds of editfunctions comes up.
2.He clicks CopyIETM to make a copy of the old IETM version, because the onging work oder makes use of it. 3.He activates the EditText function, and select the UT:Help section to change the content of it. 4.After that, he activates the EditImage function to add a new picture into the document. 5.And then, he wants to save it using UC:CommitIETM function. But, by mistake he clicks the DeleteIETM button. 6.Don't worry! The system displays a warning message and prompts to confirm the deletion. 7.He answers with 'No'.The system comes back to the previous. 8.He clicks UC:CommitIETM button and saves the IETM new version as "IETM2.0". |
|||
Preconditions: | |||
1. The A:IETM
Maintainer has just received a IETM working package from the Device
Provider, and installed it into the IETM System. So he must change the
UT:Help
section of the old IETM version, so that the A:Supervisor
can initiate new work order according to it, and the A:Technician
can know, how to work step by step.
2.He has activated the UC:OpenIETM function. |
|||
Exit conditions: | |||
The desired action is applied to the IETM | |||
Exceptions: | |||
1.UC:ConnectionDown
happens during fetching for copy and the whole IETM is deleted.
so we'd better make a backup of IETM previously. 2.UC:NotifyIETM is activited. Alarm sounds. The A:IETM Maintainer stops his work immediately to deal with the emergency. |
|||
Services: | |||
No services specified. | |||
4.6. Enter-room-IS | |||
Realized User Task: | |||
Find Location & Resources | |||
Flow of events: | |||
1) A:Technician
passes a door.
2) A Sensor registers that the A:Technician has entered a particular room. 3) The S:IS-Client is informed about that event. |
|||
Services: | |||
No services specified. | |||
4.7. Execute Work Order UC | |||
Realized User Task: | |||
Execute Work Order | |||
Flow of events: | |||
The technicUC:SelectWorkOrder
and all the steps of the current workflow are displayed by showworkflow.
After having finished a workstep he invokes UC:acknowledgeWorkstep.
During the whole use case the A:Technician can send messages to the A:Supervisor by notifyA:Supervisor. If there is no network connection available the A:Technician is informed of the occuring UC:NoSuperVisConnection. If the infoservice subsystem decides to do some prefetching the progress is displayed. Throughout this whole procedure the A:Technician can UC:Abort-Prefetching-IS. If the system expects the A:Technician to enter some data the UC:InputValue is executed. The A:Technician can request additional general information via the UC:getGeneralInfo at any moment during his work. |
|||
Services: | |||
No services specified. | |||
4.8. FindWay | |||
Realized User Task: | |||
Find Location & Resources | |||
Flow of events: | |||
1) The Mobile-Computer of the technician is
asked about its currrent position (see GetCurrentPosition of A:Technician) 2) The S:Locator-Service is asked about the position of the target ressource or location. 3) The S:Locator-Service is given these two coordinates and asked to find a way. 4) The proposed way is delivered back. |
|||
Services: | |||
No services specified. | |||
4.9. GetCurrentPositionOfTechnician | |||
Realized User Task: | |||
Find Location & Resources | |||
Flow of events: | |||
1) The Mobile-Computer of the A:Technician
knows exactly where it is located at and in which direction it"s user is looking. 2) The answer is given in terms of (GPS?) coordinates with an additional direction component. |
|||
Services: | |||
No services specified. | |||
4.10. GetTargetPosition | |||
Realized User Task: | |||
Find Location & Resources | |||
Flow of events: | |||
1) The S:Locator-Service
is asked about the location
of a room or ressource. 2) The S:Locator-Service knows where each room or ressource is situated and provides an answer in terms of (GPS?) coordinates. |
|||
Services: | |||
No services specified. | |||
4.11. InputValue | |||
Realized User Task: | |||
Execute Work Order | |||
Flow of events: | |||
1. system waits for any kind of input (speech, easy dial,
...) and assigns its value to the current step in the workflow
2. the value is repeated to inform A:Technician what the system understood 3a. in case A:Technician informs system that the value is wrong -> system waits for new input (goto 1.) |
|||
Preconditions: | |||
current workflow is at a point where input (of values) is required or A:Technician wants to change a previous value | |||
Exit conditions: | |||
1. system acknoeledges current workstep
2. proceed in the workflow (-> UC:show Workflow) |
|||
Nonfunctional Constraints: | |||
Compliance to procedures | |||
Services: | |||
No services specified. | |||
4.12. InstallPackage | |||
Realized User Task: | |||
Upgrade IETM | |||
Flow of events: | |||
1. The A:IETM
Maintainer selects an IETM package file with a file chooser.
2. Information is extracted from the package file (name of IETM, manufacturer, version,...) and presented to the A:IETM Maintainer. He is also asked whether to install this package or view locally or cancel. 3. If he chooses - install, the IETM is extracted and send to the IETMDB (see UC:CommitIETM use case). - view, the IETM is extracted to the local machine and a new IETM is created. The view changes to the one described in the UC:NotifyIETM use case. After viewing, the A:IETM Maintainer has still the chance to UC:CommitIETM. - cancel aborts the installation process. |
|||
Preconditions: | |||
The A:IETM Maintainer presses the "install package" button. | |||
Exit conditions: | |||
After installing the IETM or IETM section is properly saved to the IETMDB. | |||
Services: | |||
No services specified. | |||
4.13. Interrupt-Prefetching-IS | |||
Realized User Task: | |||
No user task specified. | |||
Flow of events: | |||
The currently running Prefetch method is suspend and can be continued later (see UC:Continue-Prefetching-IS). | |||
Services: | |||
No services specified. | |||
4.14. NoSuperVisConnection | |||
Realized User Task: | |||
Execute Work Order | |||
Flow of events: | |||
1. A:Technician
is notified of the exception.
2. All requests are queued to be send to the A:Supervisor when connection available again. |
|||
Preconditions: | |||
A notify A:Supervisor
request occured.
An exception occured because the connection is lost for any reason. |
|||
Exit conditions: | |||
None of the requests get lost during the UT:Execute Work Order. They are send to the A:Supervisor as soon as connection is accessible again. | |||
Services: | |||
No services specified. | |||
4.15. Notify Supervisor | |||
Realized User Task: | |||
Execute Work Order | |||
Flow of events: | |||
a message is sent to the A:Supervisor of various content e.g. Workstep done, need further UT:Help | |||
Exit conditions: | |||
handle message received acknowledgement sent by A:Supervisor | |||
Exceptions: | |||
UC:NoSuperVisConnection | |||
Services: | |||
No services specified. | |||
4.16. NotifyIETM | |||
Realized User Task: | |||
Upgrade IETM | |||
Flow of events: | |||
1. An emergerncy comes up suddenly.
System gives automatisch an alarm signal. Oder someone findes an emergency, oder Someone wntes to send a instant messege to someone else, he activates the UC:UC:NotifyIETM function. 2. A:A:Technician, IETMmaintainer, A:Supervirm and act properly and immediately. |
|||
Preconditions: | |||
There's something wrong in the interaction between system
and environment.
Oder a communication needs to de set immediately. |
|||
Exit conditions: | |||
Everything is setteled down. | |||
Exceptions: | |||
UC:ConnectionDown | |||
Nonfunctional Constraints: | |||
Flexible UI Devices | |||
Services: | |||
No services specified. | |||
4.17. OpenIETM | |||
Realized User Task: | |||
Upgrade IETM | |||
Flow of events: | |||
1. The A:IETM
Maintainer invoked UC:OpenIETM
function. The system reacted with presenting a window with two choices
, " UC:InstallPackage"
oder "UC:EditIETM".
2. The A:IETM Maintainer sets the disk into the laufwerk and activates the "UC:InstallPackage" function. The system set up the IETM Pachage automatically. 3. The A:IETM Maintainer invokes the "Commit IETM" to affirm the change. 4. The A:IETM Maintainer activates the " UC:EditIETM" function to write the new UT:Help information into IETM. 5. After that, he clicks " UC:CommitIETM" button to affirm the change. |
|||
Preconditions: | |||
A:IETM Maintainer wants to install a new working package oder change the content of IETM Document. He presses the "UC:OpenIETM" button. | |||
Exit conditions: | |||
IETM Maintainter closes "UC:OpenIETM" window. | |||
Exceptions: | |||
UC:ConnectionDown
UC:NotifyIETM |
|||
Services: | |||
No services specified. | |||
4.18. Read-IS-Client-Status | |||
Realized User Task: | |||
Find Location & Resources | |||
Flow of events: | |||
A A:Technician
can request
the status of the S:IS-Client running on his Mobile-Computer. This status consists of information about: - the current room. - the estimated download time for the currently running request. - the network connection which is used at the moment (Ethernet or Wireless LAN) |
|||
Services: | |||
No services specified. | |||
4.19. Request-based-Prefetch-IS | |||
Realized User Task: | |||
Request Data-IS | |||
Flow of events: | |||
1) A:Technician
clicks on a hyperlink or enters
an url for an IETM-document d in the GUI 2) The GE:Mobile-GUI-IS requests this document d from the S:IS-Client. 3) The S:IS-Client generates a list of documents which are likely to be used in connection with d (based on statistical knowledge) 4) The S:IS-Client reqests d and all documents on that list from the S:IS-Server (see also UT:Request Data-IS) |
|||
Nonfunctional Constraints: | |||
Load user-requested data first | |||
Services: | |||
No services specified. | |||
4.20. Room-based-Prefetch-IS | |||
Realized User Task: | |||
No user task specified. | |||
Flow of events: | |||
1) The S:IS-Client
is notified about entering a particular room.
2) The S:IS-Client generates a list of documents which are likely to be important for this room (based on statistical knowledge) 3) The S:IS-Client requests all documents on that list from the S:IS-Server (see also UT:Request Data-IS) 4) The download of all these documents begins. |
|||
Services: | |||
No services specified. | |||
Open Questions: | |||
What happens if the prefetching does not guess correctly the list of documents? | |||
4.21. SelectWorkOrder | |||
Realized User Task: | |||
Execute Work Order | |||
Flow of events: | |||
The A:Technician
selects freely one of the workorders assigned to him from the "work"-menu
on the LCD. The workorder is initialized automatically by the system and
a scrollable window under the "work"-menu on the LCD shows all worksteps.
If there is no LCD available, the first workorder is selected automatically by the system. The A:Technician just has to initialize it by an appropriate spoken command. |
|||
Preconditions: | |||
The A:Technician is currently not executing any workorder and is still on duty so that he has to keep on working. | |||
Exit conditions: | |||
The AR-window on the LCD and/or the HMD show the first workstep. | |||
Services: | |||
No services specified. | |||
4.22. Workorder-based-Prefetch-IS | |||
Realized User Task: | |||
Initiate Work Order | |||
Flow of events: | |||
1) The A:Supervisor
gives a new workorder to a A:Technician.
2) The A:Technician's mobile computer (S:IS-Client) is notified about this new workorder. 3) The S:IS-Client generates a list of documents, which are important for the new workorder (based on a statistical knowledge) 4) The S:IS-Client requests each GE:Data-IS from that list from the S:IS-Server. (see also UT:Request Data-IS) These documents are copied to the Mobile-GE:Cache-IS. |
|||
Services: | |||
No services specified. | |||
4.23. acknowledgeWorkstep | |||
Realized User Task: | |||
Execute Work Order | |||
Flow of events: | |||
1. The A:Technician
acknowledges the current Workstep to have done
2. The system informs A:Supervisor , which workstep was done (-> Use Case notify A:Supervisor) note: as A:Technician must acknowledge every workstep to proceed in his workflow -> he can only invoke this UC when he wants to acknowledge the current workstep -> no further exceptions |
|||
Preconditions: | |||
all previous worksteps in the workflow diagram are acknowledged | |||
Exit conditions: | |||
show next worksteps (-> Use Case UC:show Workflow) | |||
Nonfunctional Constraints: | |||
Compliance to procedures | |||
Services: | |||
No services specified. | |||
4.24. assign work order to technician | |||
Realized User Task: | |||
Initiate Work Order | |||
Flow of events: | |||
1. The system lists all created work orders.
2. The A:Supervisor choose a work order. 3. A list with all available A:Technicians with the required skills appear. 4. The A:Supervisor select the the A:Technician to carry out the current work order |
|||
Preconditions: | |||
This use case starts when the A:Supervisor activates the "assign work order to A:Technician" function using his computer system. | |||
Exit conditions: | |||
This use case ends if the A:Supervisor pushes an exit button. The assignment will be saved and A:Supervisor will be acknowledged | |||
Exceptions: | |||
1. The A:Supervisor
is notified immediately if access to stored created work orders is not
available
2. The A:Supervisor is notified if there is no A:Technician available equipped with the required skills. |
|||
Nonfunctional Constraints: | |||
Matching work order with skills | |||
Services: | |||
No services specified. | |||
4.25. create work order | |||
Realized User Task: | |||
Initiate Work Order | |||
Flow of events: | |||
1. The system lists the available IETM procedures.
2. The A:Supervisor selects some procedures from the list. 3. The system displays some input fields for additional information like date of execution, an informal description and the neccessary A:Technician skills. 4. The A:Supervisor inputs the intended date, the neccessary skills and an optional informal description. |
|||
Preconditions: | |||
This use case starts when the A:Supervisor activates the "UC:create work order" function using his computer system. | |||
Exit conditions: | |||
The system acknowledges the input and deposit of the entered data. | |||
Exceptions: | |||
Due to any system error, the A:Supervisor is notified and the creation procedure gets aborted after the state of the work order creation has been saved, that was approached so far. | |||
Services: | |||
No services specified. | |||
4.26. getGeneralInfo | |||
Realized User Task: | |||
Execute Work Order | |||
Flow of events: | |||
1. The A:Technician
selects an item on his LCD, a workstep or a selectable object in his field
of vision via the HMD.
2. He activates the getInfo function 3. The system displays the requested info on the LCD 4. When the A:Technician doesn' t need the information any more he exits this use case |
|||
Exit conditions: | |||
the system is in the same state as it was when the A:Technician entered this use case | |||
Services: | |||
No services specified. | |||
4.27. manage work order | |||
Realized User Task: | |||
Initiate Work Order | |||
Flow of events: | |||
1. The system lists all created work orders .
2. The A:Supervisor choose a work order and choose between the edit and the delete function. 3. If the A:Supervisor activates the delete function, the selected work order will be destroyed and disappears from the list of work orders 4. If the A:Supervisor activates the edit function an editable form with all the information of the work order appears 5. The A:Supervisor can edit and substitute current work order information |
|||
Preconditions: | |||
this use case starts when the A:Supervisor activates the "edit/delete work order" function using his computer system. | |||
Exit conditions: | |||
This use case ends if the A:Supervisor pushes the supersede button. Edited work order will be replaced and the success will be acknowledged. | |||
Exceptions: | |||
1. The A:Supervisor is notified if access to "work order deposit" ist not available. | |||
Services: | |||
No services specified. | |||
4.28. notify technician | |||
Realized User Task: | |||
Initiate Work Order | |||
Flow of events: | |||
1. The system lists all created work orders marked as assigned
2. The A:Supervisor choose a work order and activates the "notify A:Technician" function. 3. The A:Technician is notified of the work order by the system |
|||
Preconditions: | |||
This use case starts when the A:Supervisor activates the "notify A:Technician" function using his computer system and work orders are labeled as assigned. | |||
Exit conditions: | |||
This use case ends if the A:Technician acknowledges the assigned work order. | |||
Exceptions: | |||
1. The A:Supervisor
is notified immediately if the A:Technician
can't be notified, e.g. due to relay errors.
2. The A:Supervisor is notified if access to assigned work order deposit is not available |
|||
Services: | |||
No services specified. | |||
4.29. show Workflow | |||
Realized User Task: | |||
Execute Work Order | |||
Flow of events: | |||
1. A:Technician
is shown the current workstep with a small description (one or two words)
in the HMD
2. the whole workflow is shown on the LCD with the actual status (which steps are done, which steps are still to do) |
|||
Preconditions: | |||
A:Technician has received a workorder | |||
Nonfunctional Constraints: | |||
IETM Update-Executing work orders | |||
Services: | |||
No services specified. | |||
5. Services | |||
5.1. Cache-Cleaner-IS | |||
Description: | |||
The S:IS-Client
automatically manages
its GE:Cache-IS. When new GE:Data-IS items have been requested and the GE:Cache-IS is full, then the GE:Cache-IS will be cleaned up by deleting some GE:Data-IS items. The decision which GE:Data-IS gets deleted is based on a Least- Recently-Used strategy combined with Prefetch priorities. |
|||
Inputs: | |||
List of GE:Data-IS items which are currently in the GE:Cache-IS. For each GE:Cache-IS entry a duration time and a priority is recorded. The priority of an GE:Data-IS item in the GE:Cache-IS is the same as the priority of the Prefetch-method which has been used when this item was prefetched. | |||
Use cases: | |||
No use cases specified. | |||
5.2. IS-Client | |||
Description: | |||
A service which is runnnig on the A:Technician's
Mobile Computer. This service receives orders from the GE:Mobile-GUI-IS
or the A:Supervisor-GUI-IS.
Its main purpose is to handle GE:Data-IS
requests from the A:Technician.
In order to improve its performance a Mobile-Broker-IS runs its own
GE:Cache-IS. Furthermore a Mobile-Broker-IS can be asked about its status (current room, current download job(estimated time), ...). Finally a Mobile-Broker-IS can be given control orders from the A:Technician (e.g. Abort-Prefetching-IS (ignore this), Cleanup-Cache-IS (ignore this)) |
|||
Inputs: | |||
document requests (urls) and controll orders
given by a A:Technician or a A:Supervisor. |
|||
Outputs: | |||
GE:Data-IS
(html) and status information
(current room, current download job, cache size) |
|||
Use cases: | |||
No use cases specified. | |||
5.3. IS-Server | |||
Description: | |||
A service which is running on a so called
GE:Access-Point-IS. This service receives and handles UT:Request Data-IS (url). It is connected to an GE:IETM Database. Each S:IS-Server runs its own GE:Cache-IS in order to improve its performance. |
|||
Inputs: | |||
GE:Data-IS requests. | |||
Outputs: | |||
GE:Data-IS. | |||
Use cases: | |||
No use cases specified. | |||
5.4. Locator-Service | |||
Description: | |||
The Locator service answers questions about the position
of certain ressources or locations and how to find them. It has detailed
plans of the buildings and knows where certain items
are situated. |
|||
Inputs: | |||
UC:GetTargetPosition-question
UC:FindWayTo(pos:Position) -question |
|||
Outputs: | |||
Coordinates, Waydescriptions | |||
Use cases: | |||
No use cases specified. | |||
6. Nonfunctional Constraints | |||
6.1. Compliance to procedures | |||
Description: | |||
When executing a repair or maintainence procedure, a A:Technician can be allowed to see and browse all the possible steps of the procedure. However, the A:Technician should not be allowed to execute/acknowledge the steps out of order. | |||
Constrained Elements: | |||
acknowledgeWorkstep
InputValue |
|||
6.2. Flexible UI Devices | |||
Description: | |||
The UI should be planned to support additional devices that might be available in the future. | |||
Constrained Elements: | |||
NotifyIETM | |||
6.3. IETM Update-Executing work orders | |||
Description: | |||
The upgrade of an IETM should have no influence over the current execution of work orders. | |||
Constrained Elements: | |||
CommitIETM
ConnectionDown show Workflow |
|||
6.4. Load user-requested data first | |||
Description: | |||
Whenever the user requests a document while prefetching is under way and network load is high, the prefetching activities should be automatically suspended, and the requested doc should be loaded. After the requested doc is on the client, prefetching can be resumed. This all should happen automatically, without any user intervention. | |||
Constrained Elements: | |||
Request-based-Prefetch-IS | |||
6.5. Matching work order with skills | |||
Description: | |||
A work order can only be assigned to a A:Technician who has the necessary skills to carry the procedures described in the work order. | |||
Constrained Elements: | |||
assign work order to technician | |||
6.6. Response Time-Help | |||
Description: | |||
A request for UT:Help should be answered by the appropriate expert within 5 minute of the request. The request for UT:Help should be acknowledged within a minite of the request. | |||
6.7. Robustness-Technician Interface | |||
Description: | |||
The user interface for the technicial should be robust. For example, if the speech recognition fails to understand the A:Technician correctly, there should be a way for the technicial to correct his/her input. | |||
6.8. Robustness-Unreliable network service for technician | |||
Description: | |||
A:Technicians are not guaranteed a continuous wireless network service as they navigate around the powerplant. Designated areas providea reliable wireless network service and can be used as "gas stations" by the technicians, you upload all the necessary data. However, most work areas may not provide a sufficiently good enough connectivity. The system, in order to be usable, needs to assist the A:Technician in prefetching all necessary data such that the UT:Execute Work Order user task may proceed without interruption. | |||
Constrained Elements: | |||
Execute Work Order
Find Location & Resources |
|||
6.9. Security | |||
Description: | |||
Different A:Technicians and managers have different levels of security clearance when accessing the system. When looking through the heads up display, a A:Technician should not be allowed to see information that his/her clearance does not allow him/her to see. | |||
6.10. Security-Location | |||
Description: | |||
A A:Technician should not be able to find a location to which he/she does not have the clearance to access. | |||
7. Examples | |||
Actor Instances | |||
7.1. Homer | |||
Actor: | |||
Technician | |||
Description: | |||
Homer is a technician who, in this example, carries out the "Check Helium Flushing System" maintenance procedure. | |||
7.2. Mr. Smithers | |||
Actor: | |||
Supervisor | |||
Description: | |||
Mr. Smithers is Homer's supervisor. | |||
Scenarios | |||
7.3. Check Helium Flushing System with AR & speech | |||
Instantiated Use Case: | |||
No use case specified. | |||
Initiating Actor Instance: | |||
Homer | |||
Flow of events: | |||
Homer asks ?Where do I get the required equipment for this procedure?? The system highlights the room on the floor plan and updates the path. Note, at this point if AR mode had not be used, the conversational mode would have been used to look up the appropriate procedure (see flowchart diagram and schematics of the procedure), and continue with just the dialogue of the following.
On his headphones Homer hears ?Close valve V2000.? which he does. [Step 2.1] The system answers politely: ?The minimum time for the pressure to level off is two minutes?. The systems prompts him to enter the indicated pressure on PI2082: It displays ?Pressure on PI 2082? _____ mbar? and says ?Please tell me the p?? - Homer barges in ?two twenty two?. Note: the conversational mode also supports requests to repeat a previous pressure reading, the last sentence or other intra-page commands; to navigate to other steps (inter-page commands); or enable input/output channels (meta-commands). |
|||
8. Glossary | |||
8.1. Access-Point-IS | |||
Definition: | |||
A Computer with several Ethernet and Wireless-LAN
sockets. |
|||
Appears In: | |||
IS-Server | |||
8.2. Cache-IS | |||
Definition: | |||
Is a temporal memory for IETM-documents. Each
S:IS-Client and S:IS-Server has its own Cache-IS. |
|||
Appears In: | |||
Cache-Cleaner-IS
Cleanup-Cache-IS (ignore this) IS-Client IS-Server Request Data-IS Workorder-based-Prefetch-IS Workorder-based-Prefetching-IS (ignore this) |
|||
8.3. Data-IS | |||
Definition: | |||
A GE:Data-IS can be either textdata (html,xml,...) or binary data (gif,mov,jpg) | |||
Appears In: | |||
Abort-Prefetching-IS
Abort-Prefetching-IS (ignore this) Cache-Cleaner-IS Data-IS IS-Client IS-Server Request Data-IS Workorder-based-Prefetch-IS |
|||
8.4. IETM Database | |||
Definition: | |||
Holds all IETMs and associated data files (text, graphics, audio, video, etc.). | |||
Appears In: | |||
IS-Server | |||
8.5. Mobile-GUI-IS | |||
Definition: | |||
The GUI which is running on the A:Technician's Mobile Computer. | |||
Appears In: | |||
Abort-Prefetching-IS
Abort-Prefetching-IS (ignore this) IS-Client Mobile-Broker-IS Request Data-IS Request-based-Prefetch-IS Request-based-Prefetching-IS (ignore this) |
|||
9. Diagrams and Mockup | |||
Diagrams: | |||
IS client usecases
IS server usecases UI execute work order UI execute work order (small) IETM Initiate Work Order IETM Update IETM | |||
Mockup: | |||
Head Mounted Display
Portable LCD Supervisor (Mr. Smithers) |