Task Structure Methodology for Electronic Operational Documentation

航空发表于 2010-9-28 15:45:22

**** Hidden Message *****

航空发表于 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

页: [1]

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

Task Structure Methodology for Electronic Operational Documentation