=Paper=
{{Paper
|id=Vol-114/paper-10
|storemode=property
|title=Contextualised Operational Documentation: an Application Study in Aviation
|pdfUrl=https://ceur-ws.org/Vol-114/paper10.pdf
|volume=Vol-114
}}
==Contextualised Operational Documentation: an Application Study in Aviation==
https://ceur-ws.org/Vol-114/paper10.pdf
Contextualised Operational Documentation:
an Application Study in Aviation
Jean-Philippe Ramu
European Institute of Cognitive Sciences and Engineering (EURISCO International)
4, Avenue Edouard Belin
31400 Toulouse, France
+33.5.62.17.38.38
jean-philippe.ramu@onecert.fr
Abstract. This paper describes the development of a new generation of
electronic operational documentation in the aviation domain. This electronic
documentation provides the user with contextual information that is valid in a
specific situation and for a specific task. In order to author such manuals, the
information is contained in documentary units, tagged with meta-data
describing the context. Contextualised documentation becomes a support
facility addressing the actual or the expected situation of the user, both in
operation and in training. Next to the development of contextualised
documentation description, an analogy is made with instrumentation. This
analogy enables us to make a parallel between instrumentation conception and
the contextual documentation conception.
1 Introduction
In the aeronautical domain, operational manuals are the means to support the storage
and use of useful information, as well as technical facts describing or limiting
operations. The development of operational documentation is a continuous process
integrating lessons learned from on line operations or training practices and is the
technical reference for system behaviour descriptions. Lessons learned are related to
the iteration of best practices and manufacturers and airline training organisations
widely communicate them.
Despite significant advances in aircraft design, the present operational manuals
format and medium have remained basically unchanged. These manuals remain
“classic” paper documents, and are organised accordingly. However, progress has
been made in systems to store documentation electronically. Electronic
documentation introduces the concept of structured modular documentation. The
emerging computer standards such as the eXtensible Mark-up Language (XML) will
permit industrial application of object-oriented databases. In the near future,
operational documentation will migrate from static paper output to dynamic electronic
format.
Operational documentation has always been used as a reference publication and
this will always be maintained. New information technologies will permit the
continuous consultation of operational documentation enhancing its impact on the
user learning process. The availability of multiple devices and networking capabilities
will enable large amounts of information to be taken into account, as well as the
integration within the working environment of electronic operational documentation
as a performance support tool [3].
The migration of operational documentation from the status of reference to the
status of an integrated performance support tool will not be trivial. The operational
environment in aviation, especially in the aircraft cockpit, is already sustained by
information. The role of a new performance support tool will have to be identified
with respect to the existing environment. Its conception will go beyond the content of
the documentation; properties for the right exploitation of the content will have to be
specified. The changes will impact both end-user’s daily operations and training, as
well as organisation operational documentation production and culture.
In this paper, first we describe the present aviation documentation scope, then we
introduce what is the challenge of documentation contextualisation by using the
analogy of instrumentation. Next we will propose a conception methodology in order
to implement the required documentation properties. We will introduce articulation
concepts for the exploitation of electronic operational documentation in the
aeronautical domain and finally, we will discuss some issues related to training and
knowledge management aspects.
2 Operational Documentation in Aviation
Today, operational documentation deliverables are organised into products, each of
which is adequate to respond to a particular need. For example, the Flight Crew
Operational Manual (FCOM) is commonly used by aircrews, airline operations
management and planning staff as an aid to daily aircraft operation and planning. The
FCOM is used both in flight and on the ground. The Aircraft Flight Manual (AFM) is
a document that summarises the necessary information to safely operate the related
aircraft for certification purposes. The AFM information is a subgroup of the FCOM
information. The Minimum Equipment List (MEL) and the Configuration Dispatch
List (CDL) are both dispatch condition products that summarise possible aircraft
problems and their consequences. FCOM and AFM relate to MEL and CDL, and vice
versa, each time the information is complementary. MEL and CDL are at the frontier
between operation and maintenance worlds [9]. Next to the use of operational
manuals in an operational environment for support with technical documentation, they
play a role in aircrew training, and serve as a reference for the development of
training material. Computer Based Training (CBT) introduces aircrews to aircraft
system operations. It adapts operational information to the benefit of ab-initio
trainees. Even if the form of each product is different, content always consists in
providing information for operational work.
The transition from paper to electronic format will enable the integration of
documentation into one single database, eliminating today’s documentation
segmentation. It will be up to the documentation interface to filter the relevant content
with respect to its particular use. An analogy can be made with flight instruments. In
the past, instrument information was given on separate displays. It was up to the pilot
to integrate the information. Today, the information is presented in a way that enables
the pilot to see needed information at once. The transfer to electronic displays has
provided the flexibility for presenting information in an integrated manner, although
this information still comes from different sources [7]. The same kind of flexibility
should be possible for electronic operational documentation.
Assuming that operational documentation will migrate into a performance support
tool, we will use the instrumentation analogy on an example to identify the new
performance support tool specifications.
3 Anemometer Instrument: an Analogy Example
Once the aeronautical domain had identified that “speed” information is necessary
information for flight management, engineers developed the anemometer to provide
aircrew with the aircraft’s speed. In order to design such an instrument, engineers had
to consider several questions. First, what information to provide? Second, which
physical environment parameters are representative of the aircraft’s state in terms of
speed measuring? Third, understand the laws that guide the evolution of the physical
environment parameters, and fourth, to correlate those parameters to the indicator so
that the information is valid in a given “context”. The first question relates to the
information need, while the second, third and fourth questions relate to the need of
each instrument: a calibration process.
In the case of the anemometer, several theories have driven its development.
Bernouilli’s law introduced the relation between energy and aerodynamics making
possible the measurement of a given speed in respect to static and dynamic pressure
(physical environment parameters); Saint-Venant’s law generalised the theory for the
subsonic scope and Lord Rayleigh’s law extended the theory for the supersonic scope.
Anemometers are specified accordingly. Figure 1 summarises the calibration inputs
and the information output:
INSTRUMENTATION
e.g: Anemometer
CONTEXT OF USE e.g:
P static = X ; DATA e.g:
P dynamic = Y ; CALIBRATION Speed = f (P static;
Speed = V ; P dynamic)
INFORMATION
V = f (X ; Y)
Fig. 1. Calibration process input and output
Once operational documentation is available as an electronic tool, the physical
difference between instrumentation and documentation will tend to disappear. Both
concepts (instrumentation & documentation) will be able to provide digital dynamic
information. It will be necessary to differentiate instrumentation and documentation in
another way. As documentation information is the sum of available information, we
will make here the assumption that a documentation performance support tool is the
sum of instrumentation tools, and that the calibration of documentation is called
contextualisation. Figure 2 takes up the process of Figure 1 and generalises the input
and output in the case of a performance support tool:
Σ (INSTRUMENTATION) =
DOCUMENTATION
Σ (CONTEXT OF USE) = Σ (DATA) =
CONTEXTUALISATION
SITUATION COMMUNICATION
Σ (INFORMATION)
Fig. 2. Contextualisation process input and output
The questions that have been answered in the case of the anemometer have now to
be studied for the documentation, Table 1 gives the anemometer and documentation
analogy in terms of conception:
Table 1. Anemometer and Electronic Operational Documentation analogy
Anemometer Electronic Operational Documentation
1) Speed is a needed information What is the information need for an operator in
the aeronautical domain (aircrew)?
2) Static and dynamic pressure Which descriptors are relevant in terms of
have to be measured context of use in order to make possible domain
situations explicit?
3) Saint-Venant’s and Lord How to correlate communication to the
Rayleigh’s law correlate situation in order to produce information?
speed, static and dynamic
pressure
4) For dynamic pressure equal What are the possible patterns of meaning that
zero, the anemometer link together communication and situation in
indicator communicates zero order to deliver information?
4 Electronic Operational Documentation Conception
What is the information need for an operator in the aeronautical domain
(aircrew)? The aviation community already has extensive operational documentation
content. We will consider that the present operational documentation traces all needed
information and we will concentrate on the calibration of operational documentation:
a contextualisation process.
Which descriptors are relevant in terms of context of use in order to make
possible domain situations explicit? Each object of an electronic database will be
made up of data and meta-data. Data is the content of the documentation and meta-
data is a means to describe and exploit database properties with appropriate tools.
The concept of Documentary Unit (DU) is at the heart of the segmentation of
operational electronic documentation into defined entities and is the documentation
data. A DU is meant to be a granule of the structured object-oriented database and can
contain descriptions, schematics, animations, performance data etc.
Meta-data will be assigned to each DU in the form of descriptors. A descriptor is
meant to qualify the content of a DU [5]. The attribution of DU descriptors is a
process that will have to take place in parallel to DU authoring. We call
documentation contextualisation the process of assigning a set of Context Descriptors
(CD) to each DU in order to frame the DU applicability.
In order to describe the content of a DU, we have identified independent families
of CD in the flight operational domain. Each family is split into categories [11]:
• Artefact family (for technical content description), split into:
o System category (functional referential, for example “hydraulic”);
o Interface category (physical referential, for example “overhead-panel”);
• Task family (for work description), split into:
o Phases of flight category (linear work segmentation, for example “cruise”;
Phases of flight definitions have been standardised in 2002) [12];
o Operation category (parallel work segmentation, for example “descent
preparation”).
• Environment family (for conditional relevance), split into:
o External environment category (aircraft independent condition, for example
“low visibility”);
o Internal environment category (aircraft dependent condition, for example
“hydraulic pump failure”);
Each CD will translate concepts related to the operational documentation domain.
Logical relation links may be implemented between different concepts. The CD
structure will take the form of an ontology network.
In order to build the CD ontology with the defined families of CD, we define the
concept of ontology dimension. An ontology dimension will take the form of a logical
tree, with one root, multiple nodes hierarchically organised through multiple branches
as shown in Figure 3. Root and nodes are CD:
Fig. 3. Ontology dimension properties
For the Artefact family, ontology dimensions can be built with respect to System
and Interface category properties:
• System category: The Air Transport Association (ATA) chapters are a
standardised cutting out of aircraft mechanical parts [1]. There are logical
hierarchical links between CD of one (ATA) chapter ontology. For example, in
the ATA70 Power Plant chapter, “engine” is composed of: “compressor”,
“turbine”, etc. The System category will have many ontology dimensions. For
example, each ATA chapter described in the documentation may be a System
category ontology dimension. One descriptor of one ATA chapter ontology may
be linked to another ATA chapter ontology. For example, “fuel pump” may be
part of the ATA28 Fuel chapter ontology and also be part of the ATA49
Auxiliary Power Unit chapter ontology;
• Interface category is a particular ontology that is, for instance, a decomposition of
all aircraft parts that may be used or controlled by an end-user. As for the System
category ontology, there are hierarchical links between descriptors, and one CD
of one System category ontology may be linked to the Interface category
ontology. For example, “thrust lever” may be part of the Interface category
ontology and also be part of the ATA70 Power Plant chapter ontology.
Figure 4 shows how the Artefact family is articulated in order to build System and
Interface category ontology dimensions:
SYSTEM INTERFACE
CATEGORY CATEGORY
ATA X ATA Y Aircraft
A B B F F J
C D E G A
H I K A
L N
A
C A
Fig. 4. Artefact family ontology architecture
Task and Environment families are inter-related. Environment family descriptors
are conditions that will have an impact on Task family relations. For example,
“landing” (Phase of flight category) with “low visibility” (External environment
category) will have an impact on the “precision approach” (Operation category).
• Each Internal & External environment category descriptor will be the root for
constructing an ontology dimension (the “standard” root may be considered as a
particular Environment descriptor). They are directly linked to Phases of flight
category each time the Environment family descriptors imply an impact for a
particular phase of flight. There is an impact on the Task family descriptor if the
Environment family descriptor triggers or changes one Action linked to an
Operation category descriptor;
• Phases of flight and Operation categories are a segmentation of the work to
accomplish and summarize all possible planned situations. It is a compilation of
situations in a mutual inclusive system. Each Operation category descriptor is
linked to Actions in order to finalize a task analysis architecture. The first
ontology dimension that may be built will be with a particular root called
“standard”. This ontology will represent the standard practices.
Figure 5 represents the architecture obtained by building each ontology dimension
out of Task and Environment families:
EXTERNAL & INTERNAL
ENVIRONMENT CATEGORY
Standard Condit° X
PHASE OF FLIGHT
CATEGORY
A B B C
OPERATION
CATEGORY
D E F G
H J J K
ACTIONS
L P P Q
Fig. 5. Task & Environment family ontology architecture
How to correlate communication to the situation in order to produce
information? One major concern in defining DUs is the wish to be self-contained in
order to be unambiguously understood by a documentation end-user. The self-
contained characteristic is relative and we use the notion of context to frame the self-
contained property. We introduce the Documentary Group (DG) concept as being a
group of contextualised DU related to the same context. This implies that the amount
of information contained in one DG is a function of the DG context. In this paper, we
will make the hypothesis that a DG is self-contained only if we can define its content
via the context in order to frame its applicability. Documentation contextualisation is
a means to permit the segmentation of the information flow.
In order to better understand this approach, we will use the metaphor of a database
taken as a library. In a library, the granule of self-contained information may be the
book. In the section about aeronautics, we find the so-called operating manual. If the
operating manual is a self-contained manual (corresponding to the DG definition),
then what is its definition (context)? The International Civil Aeronautic Organisation
(ICAO) states in its 6th annex of the operational procedures that the definition of an
operating manual is [4]:
“Manual where are indicated all procedures, instructions and indications for the
operating personnel in the execution of their tasks.”
Thus, the operating manual DG is the sum of all DU attributed with Task family
CD.
As operating manuals in the aeronautical field are the major application of the
study, we will stick to this definition to elaborate a methodology for the correlation of
operational documentation (DU) to its context of use (CD families). Consequently, we
will use a task-oriented approach, together with the pre-defined ontology
architectures, to elaborate an operational documentation contextualisation process.
Figure 6 illustrates the process:
TASK & ENVIRONMENT FAMILY ARTEFACT FAMILY
Context Descriptors Context Descriptors
? ? ? ?
Branch Branch(es) Branch(es)
DU DU DU
ACTION
? ContentContentContent
Σ of Branches
Context Descriptors
Fig. 6. Task-oriented documentation contextualisation process
Each top-down branch of the multiple Task & Environment ontology will lead to
Actions. Each Action will trigger documentation needs in order to understand or
apply the related Action taken in its Task & Environment branch context. The DUs
that properly respond to the related Task & Environment branch context will be
attributed with the respective CD. The content of each Action and corresponding DUs
will be compared to the multiple Artefact ontology nodes of the CD structure. If an
Artefact ontology node is recognised as relevant in the Action or DU content, the
relevant bottom-up branch(es) of the Artefact ontology will be attributed as CD.
What are the possible patterns of meaning that link together communication and
situation in order to deliver information? The contextualisation process will make
it possible to extract the documentation meta-data from the documentation data, and
to homogeneously link data and meta-data together. Building contextualised
documentation will build a complex network linking together DU and CD. If we
study the case of the anemometer again, we can imagine what pattern of information
could emerge from a documentation contextualisation process. Figure 7 gives a
snapshot of a possible network around the information needed: aircraft speed; and
Figure 8 summarises the pattern in the form introduced during the anemometer case
study.
Fig. 7. Network relating data (Documentary Units) to meta-data (Context Descriptors)
Interest
e.g: Speed
Related Related
CONTEXT OF USE CONTEXTUALISED DATA
(Gear; Flaps; Ice; Weight) (DU2; DU3; DU4)
Σ (INFORMATION)
Speed = f (Gear; Flaps; Ice; Weight)
Fig. 8. Contextualised documentation pattern generation
This way of enriching information is similar to the current upgrade of glass
cockpit information driven by the shift to instrumentation digitalisation. Within a
Primary Flight Display of a modern commercial aircraft, the speed information is
contextualised in the sense that for relevant speeds, symbology will inform the aircraft
limits, for example, the maximum speed with gear and/or flaps extracted will be
indicated.
5 How to Use the Contextualised Documentation?
Next to traditional search methods such as word search and indexes, users can now
search by context. For contextual search, users have to input CD in order to filter
relevant information. Three axes may be combined to orient the input. These three
axes can be related to three direct questions the user may ask him/herself from an
operational point of view:
• What do I use?: need for knowledge on systems and interfaces that have to be
used in a given context. For example: “I want to retract my landing gear”;
• What will I do?: need for anticipation of the tasks to perform in a specific phase
of flight or during a specific operation. For example: “I want to perform a go-
around”;
• What if I have?: need for analysis of what will happen if the task is influenced by
external and/or internal conditions. For example “I have an hydraulic fault and
low visibility at my arrival airport”.
Within the framework of defined context ontology dimensions, it is possible to
initiate a dialogue between an end-user and the documentation as illustrated in the
Figure 9. In this illustration, the knowledge-level (Interest Process) allows users to
take advantage of the multiple ontology dimensions in order to refine the scope of
targeted information. For example, request for information regarding the “landing”
phase (Task family CD) especially with respect to “auto-land” system (Artefact
family CD). Another possibility is to gather user interest during documentation use.
For example, request for information regarding the “engine start” phase (Operation
family CD), availability of information with respect to engine start in “volcanic
ashes” condition (Environment family CD).
Fig. 9. User-Documentation communication model
In order to guide the User-Documentation communication model, context
descriptors properties may be used. The hierarchical structure of the ontology
dimensions may be used in order to filter the interest process. For example, using the
top levels of ontology dimensions for interest gathering, and then refining the search
within one ontology dimension.
Other context descriptor properties may also guide the User-Documentation
communication model, such as the dynamical link that timely relates Task family CD
together [6]. These kinds of properties will facilitate the production of scenarios that
are extensively used for training purposes. Figure 10 shows the possible dynamics of
the Task family. The {G; H; J} CD are from the Phase of Flight category and the
numbered CD are from the Operation category.
H: CRUISE J: DESCENT
1: CRUISE 1: DESCENT INITIATION
H1
2: DESCENT PREPARATION 2: DESCENT MONITORING
J1
H1 3: DESCENT ADJUSTEMENT
G: EN ROUTE CLIMB
1: CLIMB
Fig. 10. Phase of Flight & Operation categories dynamic links example
6 Discussion
This paper offers a method enabling a systematic definition of electronic operational
documentation properties in the aviation domain. Within this scope, exploitation of
these properties will offer interesting facilities in the enhancement of operational
documentation usability. However, the impact on the operator’s management of
information of the integration of an operational documentation tool in an operational
safety critical environment has to be studied.
The contextualisation of documentation based on a task-oriented analysis enables
the use of documentation in a scenario-based manner [10]. The correlation of
operational documentation with the possible domain situations will facilitate the use
of documentation as a training support. The contextual access to operational
documentation may enhance experience when documentation usage is the same in
training as in operations. In that case, training and operations share a common
strategy, supporting ongoing learning by making use of the contextualised
documentation [2] as illustrated in Figure 11:
DOCUMENTATION
Task oriented
Shared DU Contextual DU DU
Experience OPERATION Usage
TRAINING Scenario TASK
Fig. 11. Integrated view of Documentation, Operation, Training and Task
We see an operational documentation tool as being not only an individual task
performance and learning aide, but also an integrated communication system that is
connected to the knowledge management processes of the organisation. Defining a set
of context descriptors involved in the authoring process and in the end-use of
documentation will construct a common referential between authors and end-users [8]
and will facilitate the organisational learning capabilities. This common referential
aims at defining the documentation to be issued in respect to operational
requirements. The iteration of this common referential, together with its associated
documentation, may be an answer to the first question of our conception framework:
What is the information need?
Acknowledgment
Thank you to all persons involved in the migration of operational documentation
towards a digital format, and their belief in the benefit of a documentation effort.
Thank you particularly to Helen Wilson, Yvonne Barnard and Guy Boy from
EURISCO International for their support.
References
1. ATA Air Transport Association.
URL: http://www.airlines.org/home/default.aspx
2. Barnard, Y., Boy, G., Trémaud, M., Payeur, F., Fauré, X. (2002). Articulation of
Operational and Training Materials. In S. Chatty, J. Hansman, & G. Boy,
Proceedings of the International Conference on Human-Computer Interaction in
Aeronautics, p.30-35. Menlo Park, California: AAAI Press.
3. Barrera Esquinas, J.; Durstewitz, M. (2002). Evolution of Human-Device in the
Field of Technical Documentation. In S. Chatty, J. Hansman, & G. Boy,
Proceedings of the International Conference on Human-Computer Interaction in
Aeronautics, p.80-86. Menlo Park, California: AAAI Press.
4. Beillard, A. (2002). Procédures opérationnelles – Généralités. Institut
Aéronautique Jean Mermoz.
5. Boy, G. (1992). Semantic Correlation in Context: Application in document
comparaison. La Correlation, colloque international, Académie des Sciences et
Académie National de l’Air et de l’Espace, Cépaduès édition, Toulouse.
6. Boy, G. (1998). Cognitive Function Analysis. Stanford, CT: Ablex Publishing
Corporation.
7. Braca, P., Grégori, J.-P. (2000). Connaissance Aéronefs – Instrumentation.
Institut Aéronautique Jean Mermoz.
8. Hoc, J.-M. (2003). Coopération humaine et systèmes coopératifs. Ingénerie
Cognitive. France: Lavoisier.
9. Payeur, F. (2001). A380 FCOM Product Specification Business Requirements
Document. Airbus Technical Report. Toulouse, France: Airbus.
10. Ramu, J.-P. (2002). Task Structure Methodology for Electronic Operational
Documentation. In S. Chatty, J. Hansman, & G. Boy, Proceedings of the
International Conference on Human-Computer Interaction in Aeronautics, p. 62-
68. Menlo Park, California: AAAI Press.
11. Ramu, J.-P. et al. (2003). Contextualised Operational Documentation in Aviation.
Proceedings of the Human Factor in Ergonomic Society – Europe Chapter. To be
published.
12. 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.