航空论坛_航空翻译_民航英语翻译_飞行翻译

标题: Task Structure Methodology for Electronic Operational Documentation [打印本页]

作者: 航空 时间: 2010-9-28 15:45:22 标题: Task Structure Methodology for Electronic Operational Documentation

作者: 航空 时间: 2010-9-28 15:45:40

Task Structure Methodology
for Electronic Operational Documentation
Jean-Philippe Ramu
European Institute of Cognitive Sciences and Engineering (EURISCO)
4, Avenue Edouard Belin
31400 Toulouse, France
+33.5.62.17.38.38
Jean-Philippe.Ramu@onecert.fr
Abstract
This paper discusses a methodology that enables the
incremental construction of task-oriented electronic
operational documentation. In the past, all technical
documentation was written in paper format, and
traditionally organized from an engineering point of view.
The evolution towards electronic support offers the
opportunity to re-organize operational documentation in
order to improve its usefulness and usability. We used a
user centered approach, based on task analysis, to design
electronic operational documentation to be used in both
operations and training.
Introduction
The Flight Crew Operating Manual (FCOM) is an official
document complementary to the Flight Manual. It is
commonly used by crews, airline operations management
and planning staff as an aid to daily aircraft operation and
planning. In spite of significant advances in aircraft design,
the FCOM format and medium have remained basically
unchanged for years. The FCOM continues as a “classic”
paper document, and is as such organized. However,
advances have been made in systems for storing
documentation electronically. These advances have the
potential to reduce the search and retrieval time for
information.
Next to the use of the FCOM in the cockpit for support
of the aircrew with technical documentation, this manual
plays a role in the training of aircrew, and serves as a
reference for training material. The introduction of new
FCOM delivery media, such as an Electronic FCOM
(EFCOM), offers also new possibilities to improve the
articulation between operational and training materials.
Within the development phase of the A380 aircraft, new
concepts for the FCOM are being discussed by Airbus.
Articulation between FCOM And Courseware/ Training
(ArtiFACT) project’s objective is to investigate the
opportunities for articulating the FCOM and the
courseware, in such a way that both uses (operation and
training) are better served (Barnard et al., 2002). This
study took place within this project.
An electronic form of the Airbus family FCOM does
already exist, and mirrors the existing paper one. We
Copyright © 2002, American Association for Artificial Intelligence
(www.aaai.org). All rights reserved.
further investigated how to restructure technical electronic
documentation in such a way that it is in accordance with
the cognitive work of end users, essentially in an
operational environment. In such a perspective, Airbus
defines FCOM requirements as (Trémaud, 1996):
- pilot, line operations and training oriented;
- contextual;
- easy to understand, easy to use and practical;
- self contained and self sufficient;
- accurate, dependable and stable.
This paper focuses on a contextual, pilot oriented use of
operational documentation (Trémaud, 2000 & Gillett,
Barnard, Boy 2001). Although this study took place under
the development of a new generation FCOM, the concepts
developed in this paper are relevant for other kinds of
technical electronic documentation used in operational
environments.
First we will discuss the principal changes that electronic
documentation can bring. Then, we will introduce the taskbased
philosophy and define some tool concepts for its
application. The task structure methodology for
documentation construction uses these concepts. Next, the
development of a demonstrator is described. Finally the
improvement of documentation by using the task structure
methodology is discussed.
Electronic Documentation
For a paper-based document, the properties of documentation
are its organization in chapters, and its linear coherence
with physical page attribution and format. With
electronic documentation, these properties will no longer
exist, and new properties have to be defined. The concept
of Documentary Unit (DU) is at the heart of segmentation
of electronic documentation into defined entities for
revision purpose (Payeur, 2001). A DU will have a small
size, in terms of text, usually a paragraph, and can contain
descriptions, schematics, animations, performance data etc.
Each of these entities may be hierarchically organized into
levels of sub-DUs.
For flight operational needs, the relevant information
will be split into six user-oriented domains:
Procedures (meant as commented procedures);
Description;
Limitations;
62 HCI-Aero 2002
From: HCI-02 Proceedings. Copyright © 2002, AAAI (www.aaai.org). All rights reserved.
Performances;
Supplementary techniques;
Dispatch requirements (i.e. MEL and CDL).
From a database structure point of view, we cannot
consider splitting the whole database into the six domains.
DUs like warnings, notes or sounds can be floating sub-
DUs between domains. Domain definition is an interface
concept describing the documentation and enabling the
user to structure his or her navigation.
For retrieval purposes, descriptors will be assigned to
each self-sufficient DU. A DU descriptor is meant to
qualify the content of a DU. DU descriptor attribution is a
process which will have to take place in parallel with DU
construction. Descriptors can be split into families, such
as:
Domain Descriptors;
Context Descriptors;
Task Descriptors;
Revision Descriptors.
These families are needed for EFCOM use, but more
families can be defined if necessary.
Contextual Documentation
There are two principal ways of describing a context. The
system approach or the task approach. The system
approach is an engineering approach, and groups the
information into topics. The task approach is a usercentered
approach describing a particular situation. These
two approaches are complementary. A system can include
information considering several tasks, and to accomplish a
task, several systems can be needed. For instance, a
context description in operation could be: “Limitation
(Domain Descriptor) of the landing gear (Context
Descriptor) in taxi (Task Descriptor)”. This property is a
great advantage for information retrieval. A smaller set can
be chosen with an overlapping system of information
description than with a mutual inclusive system. It is true
as long as the documentation description is exhaustive.
Users who want to answer questions like: what do I have
to do if?; what are the limitations?; how does the system
work?; will build the Manual Context by entering one or
several keywords. From this list of keywords, all relevant
DUs will be activated. A thesaurus will help compare
descriptors to keywords.
Beside information retrieval, one of the most attractive
possibilities of electronic material is interaction between
systems. An issue of context-driven concept is to let the
aircraft data help provide the context. For instance, if a
failure occurs, the documentation used in operation should
not display information in discordance with this particular
context. This help is called context-sensitive help (Boy,
1998). A one way link from the aircraft systems to the
EFCOM should permit, when wished, to dynamically
overlay the actual state of the aircraft to the available
documentation.
Task Structure Philosophy
Why a Task-based Structure?
Because one of the top requirements is to be pilot-oriented,
let’s get into a pilot’s skin. The main property of aircrew
work is to be guided by the time line. Along this time line,
the past cannot be changed, and will condition the
immediate future. If the aircrew does not take into account
(and accepts) this property, then they will not be able to
accomplish their work under time pressure.
Operational documentation can be seen like a cane. A
cane helps its user to accomplish a task (going from A to
B). But the cane is useless if its use does not match the
way the user accomplishes the task (walking). In the same
way, if operational documentation cannot be related to the
user’s cognitive structure, then its utility in an operational
environment will be minimal. The goal of the task-based
structure is to articulate the relation between documentation
and operation. To reach this goal, it is necessary to
build the DU database in such a way that each DU is related
to its context of use.
Technical writers cannot fully anticipate all the contexts
of use of a piece of information. This is the reason why an
iterative process has to take place with end users to build
up a useful DU database. A task-based structure, in the
form of an exhaustive task tree, would be the backbone of
database construction, and would guarantee a coherent task
description of the documentation. Such a structure is the
interface between documentation from technical writers
and operations by end users.
Task-Block Concept
In an operational environment, a task can be seen as a set
of actions that has to be performed in a certain context. In
an aeronautical operational environment, this concept is
implicitly present, based on experience knowledge and
feedback. The smallest operational element of this concept
is clearly defined, and known as procedures. A task can be
represented as a Task-Block (or Interaction Block (Boy,
1998)), taking into account its context history through
Task Descriptors (TD), and leading to a set of actions.
Actions can be explicit like procedures, but is a more
general concept meant to define, describe and qualify the
necessary knowledge, skills and attitude needed to face a
situation. The Task-Block concept is a way to explicitate
the context of use of each related documentation.
Task-Block properties are:
Linear browse: Task-Blocks are linked. Each link is a one
way link and comes from (leads to) another Task-Block;
and Mutual Inclusion: a context of Task-Block can be a
Task-Block itself.
Task-Block organization. Following the property of
mutual inclusion, we will build the Task-Block
organization taking the example of a house.
- A Task-Block is characterized by the TD history
- A TD history must have one house TD (first layer)
HCI-Aero 2002 63
- A TD history may have one (or more) room TD (second
layer). Room TD can be mutual inclusive.
- A TD history may have one or more pieces of furniture
TD (third layer)
Figure 1: Task-Block & TD history organization
Task-Block links. The links between Task-Blocks will
principally reflect the one way time line property of flight.
Links can be of three different kinds: normal links,
abnormal links or emergency links. Links between Task-
Blocks are one way links. Two Task-Blocks are called
neighbors if a link connects them.
Two families of links are possible:
- Action Links: which are characterized by a change (add
or replacement) of room TD;
- Reaction Links: which are characterized by an addition
of furniture TD.
Construction of Documentation
Because task definition calls for documentation
(procedures, system explanation,…), but also
documentation demands further task definitions (possible
failures, supplementary techniques,…), construction of
documentation has to be an iterative process to ensure a
complete structure.
Initial Task-Block Tree
Let’s get back into a pilot’s skin. your job is to accomplish
a flight from Toulouse to Chicago with an A380. This
context can be seen as the first layer of TD. Implication of
the destination is beyond the scope of the present FCOM,
but aircraft type and version have to be considered. It will
be our house TD. You already know you will have to
proceed through different phases like preparation, departure,
cruise and arrival. These flight phases have been
analyzed and described for standardization purposes
(Travers, 2000). They can be seen as the second layer of
TD for your job. These flight phases are linearly defined,
and each one of them is independent. They can be
considered as room TD. For each of these phases, experience
has brought Standard Operation Procedures (SOP),
which are aircraft dependent, and enable you to operate
safely under normal conditions. These SOP definitions
would be the first apparent structure of the documentation
construction (figure 2).
Principally, the initial Task-Block tree can be
characterized by the first two layers of TD. This initial
Task-Block tree construction is a mutual inclusive segmentation
of the considered house task, and should define
all related systems. Each of these Task-Blocks will call for
procedures, but also for all relevant information useful for
the user to be able to accomplish them.
All the links that are defined during the initial Task-
Block tree construction are Action Links. A scenario is a
particular path through the Task-Block tree that makes it
possible to accomplish part of the house task. The
complete SOP tree should build a solid, useful and well
known structure to enable the first step of DU database
construction.
Initial Construction of Documentation
Once a Task-Block is defined, the technical writer will
write all information which appears necessary in the
situation described through the TD history. This process
should take place in an iterative way with end users. The
documentation will be written for the six predefined
domains.
To assure a good coherence of the documentation, the
technical writer should write the domain related DUs in a
linear order. The relative position of the DUs inside a
particular domain should be kept in memory to enable a
coherent reconstruction of Task-Block related domains
even if some DUs are missing (due to Context Descriptors
choices). Similarly to the DU/sub-DU construction, the
domain is an ordered succession of DU-Links, which
points to all DUs defined during documentation construction.
Such a construction could lead to much redundant
information between two neighbor Task-Blocks. A tool
facility for the technical writer should allow him/her to
pick up DUs already created for neighbor Task-Blocks,
and he/she would then modify, add or complete, in an
iterative manner, Task-Blocks documentation.
64 HCI-Aero 2002
Figure 2: Initial Task-Block tree example
All DUs created in this manner get their attributes from
the TD history used to define them. It is a cumulative
process, if a DU is used under several Task-Blocks, then it
will be attributed all TDs of the multiple Task-Blocks’ TD
history. This process will enable technical writers to
implicitly connect the context of use to the documentation
during the data construction.
In parallel, the technical writers will define for each DU
relevant Context Descriptors (for example an ATA
chapter) for information retrieval purposes.
Augmented Task-Block Tree
Once created, the initial Task-Block tree should summarize
all the planned tactics that the aircrew could encounter
during the flight. Running through a particular scenario of
one of these tactics can be schematized in a linear form
considering the one way time line property. All the present
links that connect all flight tasks are Action Links. If a non
standard situation occurs, a scenario has to remain possible
(under conditions). The purpose of Reaction Links is to
define all possible non standard situations that can arise.
For instance, if a failure occurs, this fault can be considered
as a furniture TD, and remains true during the rest
of the flight. If information is demanded, then the choice of
documentation has to take into account this restriction.
Parallel scenarios can be built which will again be the base
and structure for further documentation construction
(abnormal procedures, supplementary techniques,…).
Many events can occur at any time during a flight. Two
parallel scenarios are characterized by adding the same
furniture TD to it. Links that connect two parallel scenarios
are in-line Reaction Links (or “weak links” using the
Interaction Block terminology). An in-line Reaction Link
is a link between two Task-Blocks with adding furniture
TD(s) in the TD history.
It can happen that during the flight, an event pushes a
change in the tactics. In that case, adding a furniture TD
will force a change of room TD. Those links are called outof-
line Reaction Links (or “strong links” using the
Interaction Block terminology). An out-of-line Reaction
Link is a link between two Task-Blocks with adding
furniture TD(s) and change of room TD(s) in the TD
history.
All relevant furniture TD in a TD history will have to be
taken into account to build a complete Task-Block tree
(figure 3).
HCI-Aero 2002 65
Figure 3: in-line R. Link and out-of-line R. Link
Augmented cCnstruction of Documentation
The process of documentation construction out of each
Task-Block remains the same as explained for the initial
documentation construction.
However, some documentation will be necessary which
is not directly related to the Task-Blocks, but related to the
Reaction Links defined. For instance, some specific
procedures will have to be applied if a particular failure
occurs during a particular situation. The operational principles
can be considered in this augmented documentation
construction:
- The “STATUS” concept can be directly associated with
a Reaction Link.
- The Minimum Equipment List (MEL) principle can be
considered as a commented summary of Reaction
Links consequences due to a particular furniture TD
considered along the further Task-Block tree. This
definition has the advantage of being applicable at any
time of the flight.
Final Structure
Once completed, the database can be seen as a forest,
where trees are the DUs with interconnected ramifications
called DU-Links (see figure 4). The DU-Links will be
active or not depending on the user’s request. Descriptors
will be attributed to each self-sufficient DU. To insure a
linear use of the DU database guided by flight operation
properties, an exhaustive Task-Block tree will be defined
and will serve as the backbone for data construction. The
coherence of information display will be assured by Task-
Block attributed domains that will be connected to the
relevant DUs. Extended possibilities of the Task-Block
tree reflection are Reaction Link consequences.
Figure 4: EFCOM final structure
Retrieval and Navigation Possibilities
In an operational environment, an important objective of
electronic documentation is to shorten information
retrieval time. Using contextual information will limit the
search space. For this purpose, the Manual Context enables
a good flexibility for choosing the right information. The
task-based structure is not directly involved in this process,
but the Descriptor concept will be used.
The Task-Block structure permits the addition of Task
Descriptors to all the DUs, and allows the user to point in a
linear document in accordance with the aircrew’s cognitive
structure. This should improve documentation description.
Pointing to a limited field of documentation in a linear
structure may reduce disorientation and cognitive overload.
In one Task-Block context hypertext facilities could be
included. This responds primarily to the need for domain
navigation purpose, to be able to easily find, for instance,
the description of one procedure, or the limitation of one
description. Between two Task-Blocks, hyperlinks should
be unnecessary because the available information will be
redundant between two neighbor Task-Blocks.
The step-by-step navigation facility using the Task-
Block tree is not always needed during operations.
However, it relates to an operational and training use.
Linear browsing through documentation using flight properties
will encourage ongoing learning, and should make it
possible to use the EFCOM effectively for training
purposes. Even if information is redundant with this
navigation, it is possible to hide the redundant information
when this facility is used, so that the consequences of
context changes are underlined.
Demonstrator Application
A Demonstrator, with the objective of simulating the final
tool, has been developed and shown to Airbus
66 HCI-Aero 2002
Figure 5: Demonstrator display example
collaborators (Ramu, 2001). The content of the
Demonstrator is directly taken from the A340 FCOM. The
demonstration of the display form was well accepted, and
it was acknowledged that it could bring a document structure
knowledge in accordance with operational and training
use.
Demonstrator display. The Demonstrator display is
divided into two parts: a menu on the left side, and the
documentation display on the right.
The documentation display uses colors. The ECAM
color code has been used for coherence principally for the
procedure domain. In the same way, the other domains will
have color attribution for their specific information. Also
the format has been defined for Procedures and
Description domains, and this format definition will have
to be extended to all domains.
The left side menu is a task-based menu following the
SOP task tree. It reflects the actual context, and links to the
neighbors’ Task-Blocks (figure 5). This menu also uses
colors, reflecting the link nature. The links implemented in
the Demonstrator are Action Links. Purple reflects normal
links, amber reflects abnormal links and red reflects emergency
links. Grey reflects links that are not directly accessible
(or inactive) and green reflects the context in use.
Demonstrator navigation. The Manual Context facility is
the primary tool for information requests. Once a choice
has been made, a menu appears forcing the user to choose
a DU from all DUs activated with the Manual Context use.
This choice will call up a Task-Block of the SOP Task-
Block tree that appears on the left side menu.
The display uses the level attribution defined in the
INFO project (Boy, Blomberg, & Petiot, 1998). The initial
documentation display is the level 1 information. A
“MORE” or “LESS” facility permits the user to display
level 1+2 then level 1+2+3 in an incremental manner. The
level change with this demonstrator is a full display level
change.
The Manual Context can be used at any time to reach
another information. The left side menu permits a step-bystep
browsing through the Task-Block tree, and guides the
documentation display in sequence. Figure 6 shows the
Demonstrator EFCOM simulation display for level 1+2 of
the SOP descent monitoring phase.
Figure 6: Demonstrator menu example
Discussion
Now that we are familiarized with a possible
documentation construction methodology, we will discuss
from a more general point of view the correlation between
the task-based structure and a possible user cognitive structure.
The direct use of technical documentation in an
operational environment comes from the immediate need
for the right information. The role of the task-based structure
in this process is to delimitate the search of
information within a situation description. Choosing one
Task-Block will provide the user with all information
HCI-Aero 2002 67
related to this particular situation, making the need for
extended information more obvious.
The structure knowledge is of indirect use. In practice,
the initial Task-Block tree can be seen as a segmentation of
the work to accomplish and summarizes all possible
planned situations. It is a compilation of situations in a
mutual inclusive system.
Once an unplanned event occurs, the structure will jump
into a parallel Task-Block tree through Reaction Links.
Basically, this can occur at any time of the life cycle of the
system, depending on the nature of the event (figures 7).
Figure 7: Task-Block tree cognitive structure
The parallel Task-Block tree is the initial Task-Block
tree image seen through a filter that has the purpose of
taking into account the unplanned event consequences. The
goal of such a structure is not to force a preferential tactic,
but to make all macroscopic reflections made during the
development phase apparent for end users (aircrew).
This conception can provide aircrew with structure
knowledge that is in accordance with additional uses of
technical operational documentation such as training,
debriefing and feedback.
The structure methodology for electronic operational
documentation relies on an extension of Travers’ flight
phases standardization It is motivated by a need for completeness
of documentation description and is an improvement
in the wish for contextualization of information.
The positive feedback from Airbus and the good
acceptance of the Demonstrator encourage us in the
opinion that a user-centered approach for technical
documentation construction and utilization is useful. Even
if the application of the study was a new generation
FCOM, this approach can be extended to more
applications with strongly dynamic environment
properties.
This structure methodology offers an opportunity to
centralize operational documentation under a form that is
in accordance with operational properties, and as a
consequence, adapted for extended use of technical
documentation for training. This approach could help
integrate all
electronic operational documentation into one tool
concept.
Acknowledgements
I would like to thank all AIRBUS participants in the
ArtiFACT project and the EURISCO colleagues for their
support and collaboration during this study.
References
Barnard, Y., Boy, G., Ramu, J.-P. & Pinet, J. (2002).
ArtiFACT Project: Articulation between FCOM and
Courseware/Training. Final Synthesis Report. EURISCO
Technical Report, T-2002-095, Toulouse, France:
EURISCO.
Trémaud, M. (1996). Aiming towards a pilot-oriented
FCOM and QRH, Objectives and guidelines. Proceedings
of the Airbus Industrie 9th Performance and Operation
Conference.
Trémaud, M. (2000). Base de Facteurs Humains pour la
conception de Systèmes Homme-Machine en aéronautique
– Définitions de Critères d’Ergonomie pour le
développement d’une Documentation Opérationnelle
Embarquée. Mémoire de D.U. Université René Descartes.
Gillett, A, Barnard, Y., & Boy, G. (2001). Research into
the Design and Development of a new Electronic Flight
Crew Operating Manual. EURISCO Technical Report, T-
2002-094. Toulouse, France: EURISCO.
Payeur, F. (2001) A380 FCOM Product Specification
Business Requirements Document. Airbus Technical
Report. Toulouse, France: Airbus.
Boy, G. (1998). Cognitive Function Analysis. Stanford,
CT: Ablex Publishing Corporation.
Travers, R.W. (2000). Pilot-Centered Phase of Flight
Standardization. In K. Abbott, J-J. Speyer, & G. Boy
(Eds.), Proceedings of the International Conference on
Human-Computer Interaction in Aeronautics (pp. 51-56).
Toulouse, France: Cépaduès-Editions.
Ramu, J.-P. (2001). Task Structure Methodology for
Electronical Operational Documentation. These Mastère
Spé
cialisé T.A.S. / Sup’Aéro. Toulouse, France: ENSAE.
Boy, G., Blomberg, R., & Petiot, E. (1998). INFO,
Information Needs for Flight Operations. Dunlap and
Associates. EURISCO Technical Report. Toulouse,
France: EURISCO.
68 HCI-Aero 2002

作者: bocome 时间: 2011-7-31 10:36:23

Operational Policies and Procedures For Pacific Oceanic and Offshore Airspace

作者: cisping 时间: 2014-5-12 21:51:49

这个要看看

作者: tonyblairer 时间: 2022-1-13 10:52:57

thanks a lot

欢迎光临航空论坛_航空翻译_民航英语翻译_飞行翻译 (http://bbs.aero.cn/)