System: STARS

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).
The goal of inspections is to find discrepancies between the specification and the actual status or behavior of a system. Example of discrepancies in an aircraft can be corrosion at the surface or low oil in the engine. 

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 sits in the control room and eats a donut
  • He gets e-mail notification of a work order for the bimonthly check of the Helium Flushing System
  • He finishes his donut
  • He supplements his working clothes with a hard hat and goggles - the hard hat includes a microphone and headphones and the goggles have an integrated computer display. The power supply, wireless networking, and sensors for his wearable computer are designed into his lab coat.
  • He authenticates himself via voice, biometrical sensors, or smartcard
  • The system welcomes him with a voice and text message ?Welcome to the bimonthly Helium Flushing System check! My sensors indicate that your current location is the Control Room. You can let me know at any time if you require navigational aid to find the Helium Flushing System or other locations in the building.?
  • Since he only had half a cup of coffee, he answers - ?Err.. what did you just say??
  • The system replies, slightly slower, ?You can let me know at any time if you require navigational aid to find the Helium Flushing System or other locations in the building.?
  • Homer answers ?Okay, please do that.?
  • His goggles now display a floor plan of the facility on which his location, the Helium Flushing System, and the path are highlighted.
  • The display indicates that there are required tools for the maintenance check

  • Homer asks ?Where do I get the required equipment for this procedure??
  • The system answers ?In Storage Room 42, Cabinet 9 - Do you want me to include this in your path?? - He answers ?Yes, please.?

  • The system highlights the room on the floor plan and updates the path.
  • Homer picks up the equipment in Storage Room 42 and continues on the indicated path to the Helium Flushing System.
  • Upon entering the room containing the Helium Flushing System the computer says ?Congratulations Homer, you found the Helium Flushing System! I can highlight the relevant system components for you.? - Homer thinks aloud ?Hmm.. It would be nice if the system components were highlighted.? which the system interprets as a positive answer.
  • The display in his goggles augments his field of vision by highlighting the components

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.

     
  • Upon request by the technician, the display updates to the first step of the maintenance procedure . The display in his goggles augments his field of vision by highlighting a valve, labelling it V2000, and displaying the word ?CLOSE? next to it.

  • On his headphones Homer hears ?Close valve V2000.? which he does. [Step 2.1]
  • Homer clicks the next button and says ?okay? to himself.
  • The system assists him with the further steps of the procedure similarly. [Step 2.2 to Step 2.8]
  • After replacing the Helium bottle at valve V2000 [Step 3.1] he then follows Step 3.2, reopening the valve V2000.
  • The display updates to a countdown waiting screen indicating the time he has to wait for the pressure to level off.
  • He grumpily asks ?Why do I have to wait??

  • The system answers politely: ?The minimum time for the pressure to level off is two minutes?.
  • Homer thinks aloud ?Oh! I see!?

  • 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?.
  • The number 22 appears in the input field. 
  • The system replies ?Since the indicated pressure is only 22 mbar, we are now switching to the Failure of Helium Flushing System procedure.?
  • Homer says ?No, the pressure was two hundred twenty two?. The system replies ?Returning to bimonthly check procedure?. The input field is updated to the number 222. The system says ?Since the indicated pressure is only 222 mbar, more Helium is needed. Close valve V2000 ?? and Homer has to repeat the steps 3.1 to 3.3.
  • The next time the reading is 420 mbar, and the system informs him that this concludes his bimonthly maintenance check procedure.
  • Homer returns to the Control Room and eats another donut. Mr. Smithers monitored Homers progress during the entire procedure on his monitor, which displayed in detail the location, actions, and timestamps for every step Homer followed in the manual.

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)
   

This page is hosted by the Chair for Applied Software Engineering of the Technische Universität München.
Imprint (Impressum)