Patent Application
20100293454
The present disclosure relates generally to pilot quick reference handbooks (QRHs), and more particularly, but not exclusively to a style guide and formatting methods for QRHs.
While operating an aircraft, a flight crew must often access one or more checklists within a quick reference handbook (QRH) in order to successfully perform their primary tasks. Because the operation of an aircraft can depend upon the proper use of a QRH checklist, it is highly desirable to provide an improved format for QRH checklists that allow for even safer aircraft operation.
Pilots work in a complex multitasking environment where many things compete for their attention. Since pilots, as do all humans, have limited attention and cognitive resources, these resources have to be distributed to the activities in which they are engaged. If one task requires a lot of the pilots' resources, then their resources may not be available for other tasks.
To successfully perform their primary tasks, crews must perform secondary or “interface management tasks”, such as physically manipulating a checklist, trying to determine what aspects of a checklist should be used in the current task, and/or accessing information in a checklist that is not readily available. In part, these secondary tasks are necessitated by the fact that crews view only a small amount of information at any given time through their flight deck displays and checklist pages.
In many human performance domains, interface management demands have been found to be excessive under some circumstances and the additional workload may interfere with a crew's ability to perform their primary tasks. Two effects have been identified, namely resource-limited effect and data-limited effect. Regarding the resource-limited effect, interface management tasks draw cognitive resources (e.g., attention, etc.) away from the primary tasks and performance declines because there are insufficient resources available for them. With the data-limited effect, primary tasks consume most of the cognitive resources leaving little for interface management performance. Since the primary tasks are dependent on interface management tasks to access the proper information, performance declines due to lack of information.
With respect to the resource-limited effect, primary task performance declines when too much attention is directed to secondary tasks. With respect to the data-limited effect, pilots manage workload by prioritizing their tasks into primary and secondary tasks. Interface management tasks are not prioritized as highly as primary tasks and sometimes are not performed. Crews will use several strategies to minimize interface management demands, such as using the currently viewed information rather than trying to retrieve the best information for the task.
Thus, interface management tasks may create barriers between crews and information. During periods of high workload, crews may decide to not access additional information because the retrieval effort may detract from the crew's primary task of handling the aircraft. Also, seeking new information may disrupt ongoing tasks or may interfere with current information being used. In some cases, crews may not access information because they do not know that it exists, such as failing to use a checklist for annunciated situations.
In summary, while checklists support the general cognitive activities of crewmembers, their use may also add to overall workload and draw resources away from the primary tasks. As noted above, the management strategy adopted by pilots to cope with this added workload can impact performance of the primary tasks.
In one aspect the present disclosure is directed to a method for generating a quick reference handbook (QRH) for a mobile platform. The method may involve providing a machine-readable medium for use with a processor having a memory. A machine-readable medium may be used to provide instructions for causing the processor to generate the QRH. The QRH may be created through the use of checklists organized in accordance with a plurality of grouping schemes, where the grouping schemes include at least a plurality of: Immediate Action; Systems; and Engine Indication and Crew Alerting System (EICAS) messages. Differentiating criteria may be used for decision steps, action steps, and navigation steps within the checklists to thereby enable a user to discriminate the decision steps, action steps, and navigation steps from each other. Related steps may be grouped within an associated checklist.
In another aspect the present disclosure involves a method for generating a quick reference handbook (QRH). The method may comprise using a processor to execute instructions for generating the QRH for use with a mobile platform. The processor may be used to organize the QRH by listing checklists within predetermined schemes including: at least one checklist involving Immediate Action items; at least one checklist involving Systems status or performance; and at least one checklist involving Engine Indication and Crew Alerting System (EICAS) messages. The processor may also be used to visually enhance an understanding of each of the checklists by using at least one of shading, graphics and color and bold font type face.
In still another aspect the present disclosure is directed to a method for generating a quick reference handbook. The method may comprising providing a processor and using the processor to create a quick reference handbook (QRH) for a mobile platform through the use of checklists. The checklists may be organized in accordance with a plurality of grouping schemes. The grouping schemes may include at least a plurality of: Immediate Action, Systems and Engine Indication and Crew Alerting System (EICAS) messages. The processor may be used to apply differentiating criteria to items listed within each of the checklists to assist a user in quickly discriminating and understanding a specific step to be taken when viewing one or more of the items listed in a specific checklist. One or more of the checklists may be displayed on a display system.
The present disclosure will become more fully understood from the detailed description and the accompanying drawings, wherein:
It should be understood that the description and specific examples set forth below, and provided in
The following description of exemplary embodiments is merely exemplary in nature and is in no way intended to limit the disclosure, its application, or uses.
Various embodiments of the present disclosure include digital or electronic data for a QRH, which may be provided in XML (extensible markup language), Framemaker, HTML (hypertext markup language), PDF (portable document format), etc. The digital or electronic version of the QRH may reside on any of a wide range of computer or machine readable media.
The digital or electronic version of the QRH may allow a user to electronically access the material, for example, while using an electronic flight bag (EFB) or other computing device. Additionally, or alternatively, the electronic QRH version may allow the user to print out the electronic QRH to create a hard copy that can then be accessed and reviewed by a user. When the electronic QRH is printed, the print version of the QRH can include at least one checklist having a format corresponding to any one of the formats described and shown herein, such as the checklist format shown in any one of
Various embodiments include a machine-readable medium for use with a processor having a memory. The machine-readable medium includes instructions to cause a processor to generate a hard copy or print copy of a QRH having at least one checklist in a format corresponding to any one of the formats described and shown herein, such as the checklist format shown in any one of
According to one aspect of the disclosure, a machine-readable medium is provided for use with a processor having a memory. The machine-readable medium includes instructions for causing the processor to generate a quick reference handbook (QRH) for a mobile platform by organizing the QRH by listing checklists within a corresponding one of a plurality of grouping schemes, the grouping schemes including Quick Action, Systems, Annunciated (e.g., EICAS Messages, Lights, etc.); using differentiating criteria for decisions steps, action steps, and navigation steps within the checklists to thereby enable a user to discriminate the decision steps, action steps, and navigation steps from each other; and visually grouping related steps within a checklist.
According to another aspect of the present disclosure, a machine-readable medium is provided for use with a processor having a memory. The machine-readable medium includes instructions for causing the processor to generate a quick reference handbook (QRH) for a mobile platform by listing additional operational considerations after an indicator that a checklist is complete, whereby the additional operational considerations provide planning information and mission consequences the crew may wish to perform due to a non-normal condition but which are not a required part of conducting the checklist.
According to another aspect of the present disclosure, a machine-readable medium is provided for use with a processor having a memory. The machine-readable medium includes instructions for causing the processor to generate a quick reference handbook (QRH) for a mobile platform by including a list of operational consequences associated with a checklist near the end of the checklist but before an indicator that the checklist is complete, whereby the operational consequences of inoperative items provide information to the user about consequences resulting from a non-normal condition.
Any of the aspects of the present disclosure can be used in combination with any one or more of the other aspects of the present disclosure.
Assumptions about flight crew competencies and conduct must be interpreted within the context of human performance. A key aspect of user-centered design is that to support skilled performance, the resources provided have to be compatible with the flight crews cognitive and information processing capabilities.
When pilots observe indications of a non-normal occurrence, the pilots try to construct a coherent explanation for the non-normal occurrence. This cognitive activity is commonly referred to as situation assessment and involves coordination between crew knowledge and experience, the external setting, and context. It is through this coordination that the crew develops an accurate understanding of the situation. These understandings may be dynamic and adaptable to new stimuli in the environment. Ideally, the crew has agreement on their individual assessments of the flight situation.
Action Response refers to deciding upon a course of action to address a situation and then taking action. In general, response planning involves using a situation model to identify objectives (e.g., stabilize the aircraft, etc.) and the transformations required to achieve them. In the absence of procedures, pilots generate alternative response plans, evaluate them, and select the most appropriate one to the current situation model. In some cases, the crew may interact with the world to gain more information about the situation or to refine their understanding of the situation. These interactions may influence future actions.
The pilots' primary tasks also include crew communications and coordination with people and events outside the aircraft, like air traffic control, operator flight management centers, and airport ground operations. Aircraft procedures and Quick Reference Handbooks (QRHs) are an integral part of the flight deck and the crew's performance of primary tasks. Aircraft procedures are designed to support the crew by providing strategies based on detailed, “off-line” analyses of both normal and non-normal states. These procedures help bridge the gap between engineering and operations.
The QRH supports several aspects of primary task performance. More specifically, the QRH supports monitoring by informing crews of the task relevant aircraft parameters. The QRH supports situation assessment by indicating the meaning of flight deck indications, guiding the decision making process by providing decision steps that structure aircraft conditions using logical statements to support the identification of a proper response plan to follow, providing rationale for better understanding of action steps, and providing information on the consequences of actions. Further, the QRH supports action response by providing pilots with step-by-step action statements to accomplish the objectives of the tasks.
Because the way a checklist is designed and formatted can greatly affect the secondary task workload it imposes, there is a need to design the QRH to minimize secondary task workload.
In addition to effects associated with workload and attention management, checklist design can also impact performance. Therefore, it is highly desirable to have QRH designs that do not include design features which make the performance of a QRH checklist susceptible to error, and thus eliminate, or at least substantially minimize, the occurrence of design-induced errors. QRH checklists are designed to at least minimize the occurrence of common design-induced errors such as misordered action-sequence errors, loss-of activation errors, capture errors, description errors, and action errors.
With respect to the cognitive challenges of managing workload in complex operational environments, the goal of user-centered design is to provide flight deck interfaces that are easy to use and minimally distract crews from their primary tasks.
Accordingly, a user interface for supporting the users thereof to efficiently and safely perform their tasks is provided. Following an extensive data collection effort involving structured interviews and questionnaires sent to aircraft operators and an analysis of existing QRH content and format, several human performance issues associated with QRH use were identified and validated including: difficulty finding the correct checklist, doing the wrong checklist, difficulty resolving decision steps with complex logical relationships (such as “if” statements, etc.), difficulty interpreting qualitative terms (such as “as required”, etc.), performing and remembering recall steps, skipping checklist steps, performing unnecessary checklist steps, losing one's place, difficulty finding supporting information needed to complete a task, difficulty using supporting information, failure to remember that a normal checklist (NC) has changed following use of a non-normal checklist (NNC), difficulty in physically handling and manipulating the QRH, and knowing when to stop.
General principles for QRH design are described below that address at least one or more of the following aspects of QRH design. These general principles of QRH design include: Accurately Represent the System, Support Crew Tasks, Meet Expectations, Minimize Secondary Tasks, Distractions, and Workload, Ensure Cognitive and Physical Compatibility, Design for Simplicity, Design for Standardization, Consistency, and Predictability, Design for Positive Guidance, Design for Discrimination, Design for Timeliness, Design for Appropriate Flexibility, Design for Tolerance to Error, and Ensure Health and Safety.
The present criteria for designing a quick reference handbook (QRH) reflect the philosophy of its use. The considerations underlying the philosophy for the design of various QRH elements are presented herein. For the purposes of describing these implications, the QRH has been characterized in terms of the design elements that make up its features and functions.
By providing improved user-centered QRHs, the present disclosure provides at least one or more of the following advantages. A first possible advantage is the reduction in the need for operators to develop and maintain a company QRH and/or reduce the amount of change needed to create a company QRH from an industry standard. This reduces operators' overall operational costs.
A second possible advantage is that the improved user-centered QRH can improve operator understanding of checklists and information in the QRH. A third possible advantage is that the QRH can further standardize operational documentation across aircraft models. Standardization reduces costs for maintaining different documents. It also reduces the operator costs for training that is associated with transitioning crews between aircraft and supports mixed-fleet flying. When crews use different formats, the probability increases for negative transfer errors in procedure and checklist use.
A fourth possible advantage of an improved user-centered QRH is that the NNC's can be characterized in terms of the design elements that make up its features and functions. QRH design is described below along the following eleven topics: (1) Role of the QRH, (2) Organization of Checklists within the QRH, (3) Checklist Selection, (4) Checklist Verification, (5) Checklist Steps, (6) Cautions and Warnings, (7) Technical Data, (8) Navigation and Place keeping Aids, (9) Supporting Information, (10) Operational Considerations, and (11) Document Characteristics.
Other important design considerations involve the context in which the QRH will be used. For example, operational environment includes design considerations that address the environmental conditions of use, such as lighting, glare, smoke, air mask, etc. Relevant factors are identified which the design can accommodate.
Another design consideration is the relationship of QRH to other user-system interfaces (USIs). The QRH is part of the overall aircraft user-system interface. These considerations address their relationship. The location of the QRH(s) supports ready retrieval and physical support for use. Tasks that rely on integrating actions and information across different user-system interfaces are supported to the extent that they are consistent, e.g., similar working, labeling, use of coding, etc.
(1) Role of the QRH
The primary purpose of the QRH is to support flight crew tasks during non-normal in-flight operations. The QRH is a single source reference document that optimally will contain all relevant guidance, information, and data needed to support the flight crew in the conduct of non-normal tasks. Information and data associated with a specific checklist are contained within the checklist, co-located with the checklist, or referenced by page number. One rationale for this is to reduce information search time and errors due to absence of information or data.
Currently, the normal checklists are included in the QRH. Preferably, however, the normal checklists are separated from non-normal checklists in the QRH thus making the normal checklist document smaller and its operation easier to navigate and manipulate.
(2) Organization of Checklists within the QRH
Organization refers to the physical arrangement of the checklists within the document. Currently, checklists are arranged alphabetically. Preferably, the organization reduces errors of selecting a checklist with a similar title and reduces navigation and search when performing tasks. To accomplish this, the following guidelines are provided.
Checklists are organized to minimize (or at least reduce) the need for navigation through the QRH. The current organization can lead to errors of selecting a checklist with a similar title. It also requires a lot of navigation when performing tasks. A task-based organization is preferable so that checklists typically used together or which commonly follow each other can be located together.
Combining multiple things into one checklist should be and preferably is avoided. Combining many situations into one checklist makes the checklist long and requires conditionals. It is generally better to have shorter checklists without conditionals.
Where possible, checklists should address less than worse-case scenarios. Normal condition checklists and non-normal condition checklists should be separated into two documents. Creating two documents will make each documents smaller, easier to navigate, and easier to manipulate.
Checklists are organized in the QRH to support non-normal tasks from beginning to end. Normal checklists that are modified due to a change in aircraft capability are appended to the non-normal checklist in the QRH, or they are clearly identified. Non-normal checklists that follow another non-normal checklist are placed after the associated checklist or are referenced by page number. All normal checklists that are not modified due to a change in aircraft capability are preferably removed from the QRH and are placed on a normal checklist card.
(3) Checklist Selection and (4) Verification
All non-normal checklists are assumed to be cue driven. The trigger is what alerts the crew that a non-normal condition exists. The triggers may originate within the flight deck (e.g., EICAS, fault light, aural warning, etc) or they may originate from some other source (e.g., noise, vibration, smell, flight attendant, etc.). A means of supporting the crew in linking a cue or constellation of cues to the appropriate checklist is preferably provided.
One rationale for this is that the crew needs to be able to verify that the found checklist is the correct checklist for the non-normal condition. It also needs to support non-native English speakers propensity to explicitly cue match EICAS messages and switch/light labels to the condition. In general, cue matching is what helps the crew verify they have identified the condition correctly and found the corresponding checklist.
Checklist Selection Guidelines
The QRH provides features to guide the pilot in selecting the proper checklist from an external triggering condition, such as a panel light, EICAS (Engine Indication and Crew Alerting System) message, or pilot identification of an unannunciated condition. These features include tables of contents, light indices, etc.
Panel lights, EICAS messages, and other triggers have maximum (or at least heightened) discriminability to minimize (or at least reduce) the chance of going to the wrong checklist. Since many messages in the cockpit have similar wording, pilots may access the wrong checklist. Enhancing the pilot's ability to discriminate between checklists helps minimize (or at least reduce the likelihood of) this error.
EICAS messages that do not have checklists are coded differently than those leading to checklists. Pilots should immediately know which messages are associated with checklists and which are not. Providing this information will reduce needless access of the QRH when no checklist exists.
“Crew awareness” checklists (carets) should be eliminated. These require navigation and pilots don't obtain any information once they access the appropriate checklist. The EICAS message alone performs this function. If a caret item has some information for the crew, then a checklist or note is provided.
When separate EICAS messages send the pilot to the same checklist, a decision step is provided to facilitate the determination of where in the checklist users should go for each particular message.
The transition from triggering message to checklist is direct with no additional cognitive analysis required. Pilots should not have to classify messages into systems and then look up the checklist in an alphabetical list by system.
When the actions required by different checklists or checklist steps conflict (e.g., set flaps at 20 degrees vs. 15 degrees, etc.), the checklist or other procedures should provide information to help pilots resolve the conflict.
When multiple triggers occur in close temporal proximity, pilots are given information to help them choose the order in which checklists are performed. A measure of support for this can be provided by using a prioritization coding scheme, similar to that used for EICAS messages. Pilots would be trained to complete higher priority checklists first. Color can be used to code checklist priority.
Checklists containing memory steps are coded in the checklist selection tables and indices. Coding this information helps alert the pilot to the existence of such steps if they somehow didn't realize these urgent steps had to be performed.
Pilots have immediate access to a list of conditions associated with checklists for unannunciated conditions. Crews often have difficulty diagnosing the condition, especially engines, and may not know which checklist is applicable to an unannunciated non-normal condition. A symptom list matrix with the list of checklists can be provided as an aid for checklist identification. Support is needed to select checklists when multiple triggers occur simultaneously.
Indexes and table of contents are designed to facilitate search. Checklists are indexed by their triggering cue. Different kinds of indexes are used to assist the crew with finding the correct checklist and they are appropriate to the aircraft: light/switch index, message index, systems index. In one prototype/exemplary concept uses several short indexes, such as Messages, Lights, Unannunciated, System Name, etc. For non-EICAS aircrafts, an exemplary QRH prototype includes Lights, Unannunciated, and System Name indexes.
Tabs to the checklist are as direct as possible to provide quick access to the correct checklist and reduce translation. Tabs are labeled on each side to facilitate search. They are also sturdy to resist wear.
Tabs are labeled by page number, although this may increase overall expense because of document management when there is a page change needed. Other suggestions included labeling by ATA coding, by section number, with system names.
Checklists are not duplicated in the QRH. Checklist titles may be duplicated across indexes. This reduces the chance of not revising a checklist during a revision cycle.
The QRH preferably provides immediate access to checklists that contain action steps that must be performed without delay. So they are easy to locate and use, immediate action or quick action checklists can be placed in the front of the QRH, in the front of their corresponding system sections, and/or they can be placed on the QRH covers. For example,
Checklist Verification Guidelines
Checklists are identified through a checklist title and other information, such as triggering information and aircraft condition giving rise to the triggers. Prototype/Exemplary concepts are provided following the guidelines below.
One guideline is to provide each checklist with a distinctive unambiguous title, and whenever possible, the title should match the cue (e.g., EICAS message or discreet light, etc.). To the greatest extent possible, the differences between titles are maximized (or at least increased) to minimize (or at least reduce) the chances of selecting the wrong checklist.
Another guideline is to have page numbers prominently and saliently displayed near the checklist title. Page numbers are used to transition from the checklist triggering condition to the checklist. Thus, the numbers are highly salient for rapid and reliable viewing.
A further guideline is to provide contextual information where needed to help ensure that the proper checklist being used is located near the title. At a minimum, that information should contain the specific triggering indicators and a statement of the underlying condition.
Contextual information is preferably visually grouped and set off from the procedure steps to enable pilots to clearly distinguish contextual information from the procedure steps so that in case of time urgency they can rapidly begin the checklist steps.
Information about the trigger condition is preferably located near the title. The corresponding lights, messages, and other conditions causing the non-normal condition will appear at the top of the checklist so the flight crew can readily verify that the correct checklist has been found. These can be color coded to match their appearance in the flight deck.
(5) Checklist Steps
Checklist steps are instructions that guide pilot actions. There are several different kinds of steps: decision steps, action steps, and navigation steps. Checklist action steps will preferably have a distinct format to represent the purpose of the step and to support easy discrimination.
Decision steps give instructions for evaluating conditions so the appropriate action can be selected from a predefined set. The decisions may involve conditional logic, i.e., where the actions are to be performed only if a specified set of conditions exists. Decision steps present conditional statements that help the pilot determine which checklist steps to use. The outcome of the step(s) is navigation within the checklist.
Decision steps are a closed system so the pilot has every possibility or combination of conditions identified, even if the combination directs the crew to another checklist. This helps prevent error. All decision consideration is grouped together so they are in one visual field. Key decision logic (such as “IF” and indentation, etc.) is replaced with symbols to avoid confusion.
Navigation steps instruct the pilot to go to a particular step in the current procedure, to go to another procedure, or to end the procedure. Action steps describe the monitoring, control, and communication actions to be taken, i.e., instructions to perform physical steps and mental ones (e.g., “verify”). Action steps may also describe the objectives of those actions. Action steps differ along dimensions of time demands and teamwork. Temporal aspects of action steps are indicated. Important actions, involving a critical control movement are highlighted.
General Guidance Regarding Checklist Steps
Each primary action step is preferably numbered. First-level checklist action steps are numbered to assist with place keeping and communication. Second level action steps are not numbered, but are presented in the sequence the crew should accomplish them.
Steps are worded in simple, precise language. Steps are also made as simple as they can be. Steps are easier to follow if the amount of text is minimized. Vague language, like “as required,” should be made precise whenever possible.
Where possible, a limited set of graphic elements should be included to rapidly convey important information. Well chosen graphics are rapidly interpreted and are less prone to error for non-native English speakers.
Steps are presented with only the information required to accomplish or understand the step. Checklist steps are one of the most important aspects of the QRH. Their presentation is as clean and uncluttered as possible. Mixing other supporting information into the steps can create distractions that can more easily result in skipping or missing a step. Methods to ensure that pilots are aware of supporting information and are guided to it are addressed in other sections of this document.
Decision steps, action steps (including recall steps), and navigation steps are easily discriminated from each other. Since the behaviors for the three types of steps are different, clearly distinguishing the types of steps helps ensure the proper behavior is accomplished.
Sensory/perception should not be a problem when appropriate font size and style is used (e.g., no font size less than 10 pts, etc.).
Support is needed (and thus preferably provided) when different steps in different checklists conflict (for example: set flaps at 20 degrees vs. 15 degrees).
Positive wording of action steps should be used when possible, with negatives being identified or highlighted so they are salient.
The flow of checklists and checklist steps preferably follows flight task sequence.
Recall Steps
Recall steps are minimized (or at least reduced) to only those actions that must be completed immediately. Memory steps are easy, do not include conditional statements, and are not mission critical (e.g., engine shutdown, etc.). Decision steps are not memory steps. These are steps that must be accomplished to prevent crew incapacitation, aircraft damage or loss of control. Since these steps must be recalled from long-term memory and are performed without reference to a checklist, they are only required when a step must be accomplished before there is sufficient time to retrieve the QRH and access the checklist. Because relying on memory can be error prone, the number of such steps is minimized. Also due to memory limitations, memory steps should not require reasoning about aircraft conditions, e.g., decision steps requiring conditional logical reasoning. Memory may degrade under stress, crews rush through steps, performing memory steps may conflict with flying the aircraft, increased opportunity for error, require training and testing.
Recall steps are presented in a convenient location that can be read within a few seconds. All recall steps must be almost immediately available once the crewmember has retrieved the QRH. One exemplary prototype concept presents the recall steps on the QRH covers or in the first few QRH pages. If recall steps are provided in a location separate from the full checklist, guidance from the end of the presentation of recall steps to the full checklist is preferably provided with clear reference to the appropriate page number. Any recall steps presented prior to referencing the full checklist should be repeated in the full checklist in a manner that visually sets them apart from non-memory steps. Clearly distinguishing recall steps from the rest of the checklist will facilitate pilots in starting at the right place in the checklist and not have to search for the proper step.
Decision Steps
The specific items to consider in the decision step are grouped together. Decision steps give instructions for evaluating conditions so the appropriate action can be selected from a predefined set. Decision steps present conditional statements that help the pilot determine which checklist steps to use. Presenting all options together will facilitate evaluating the conditions.
Preferably, decision steps are completely closed. Decision steps are a closed system, so pilot has every possibility or combination of conditions is identified (all possible outcomes are addressed). For example, in dual engine failure, guidance is provided if the engines relight or not. Each decision step should have a result, even if no further action is required.
Where possible, declarative statements of conditions are presented rather that using conditional operators. “If . . . , then . . . ” statements are normally difficult for non-native English speakers to reason about and may result in error. Significant decision terms are highlighted. This includes terms like “and” and “or.” The outcome of the decision step(s) is navigation to the proper part of the checklist or to another checklist.
Action Steps
Action statements are preferably worded, formatted, or coded to indicate the style of crew interaction and communication needed as follows. Clear initiation criteria are provided, such as a clear indication of when to start. Clear termination criteria are also provided, such as a clear indication of when to stop, even if checklist is not complete. Temporal aspects of steps are clearly indicated in the wording of the step. Important actions are highlighted. All keywords should be salient; and related steps should be visually grouped.
Navigation Steps
Navigation steps instruct the pilot to go to a particular step in the current procedure, to go to another procedure, to end the procedure, or to another place in the QRH.
(6) Cautions and Warnings
Cautions alert pilots to important preconditions or consequences of action steps. Cautions should be highly salient. Since high salience is needed (or at least preferred) for cautions, color or distinctive symbology is preferably used rather than just font coding or other less salient feature. Cautions are collocated with the appropriate step. This helps ensure that the content of the caution is read when needed. Where appropriate, information is provided as to whether the caution applies prior or after the relevant step. This helps ensure that pilots know when to read the caution with respect to the step action.
Caution and warning statements need to be visually salient. Color (in addition to distinctive symbology) can be used to discriminate between cautions and warning statements. Cautions and warning statements are preferably located near the appropriate action step so pilots are likely to read them when needed.
(7) Technical Data
Checklists preferably include technical data integral to checklist use. This data provides information that is used to tailor checklist actions. Such information can be in the form of tables, graphs, and diagrams. Technical data is presented to the flight crew in a format that is simple, contains basic values, and is easy to use and interpret. All advisory performance data are relocated to another manual.
Non-normal maneuvers are removed or co-located with the associated checklist. Maneuvers that are expected to be known by the flight crew are in the training manual and not the QRH.
Technical Data Guidelines
Information is organized by task and checklist step. The information is only as precise as needed by the task (over precision can add to complexity, time to use, and chances of error). Table and graph formatting are designed to support visual search and readability. Technical data are located near the appropriate action step but not in such as way as to divide the sequence of steps. Locating data near the steps reduces the need for pilots to navigate to it. This data is not located on the same page as the checklist steps so as to not separate sequential steps by too much information. To maintain awareness of where the checklist is going, it is important to keep steps relatively close together. Visual aids are used to assist pilots in locating supporting technical data.
(8) Navigation Aids and Placekeeping
Navigation aids and placekeeping are the design features of the QRH that provide landmarks to indicate where the pilot is in the checklist (such as page numbers, step numbers, and headings, etc.) and the design features that facilitate the location of other information within and between checklists (such as tabs, arrows, etc.). Checklists may also include aids for placekeeping (marking where a pilot is so they can more easily return).
Navigation Aids and Placekeeping Guidelines
Page or section numbers are preferably visible when the pilot is in the front of the QRH. Pilots navigate from the index to the proper checklist using page numbers. Page numbers are salient and always visible on each QRH page. Support is provided for marking the location of a needed checklist or other information. If a pilot leaves the checklist to do something else and wants to return to a particular location, marking will facilitate the transition. This can be accomplished in several ways. First, one or more “ribbon-type” bookmarks could be attached to the QRH binding. Pilots could use them as needed, to mark the location of a checklist or other supporting information. Another approach is to provide foldout tabs that can be opened. When open, the tabs are visible.
Support is provided for identifying currently active steps. Visual aids and guidance are provided when a checklist step directs the pilots' attention to another part of the checklist or supporting information. Checklists that continue from one page to the next provide markings on both top and bottom of the continuation.
Identify all crew action end points in the checklist. Identify all checklist complete points in the checklist. Use “END” or an end of checklist symbology to indicate no further crew action is needed, although there may be other information that needs to be read. Use “Checklist Complete” only when the QRH can be closed. Whenever practical one checklist will appear on a single page. In the cases where the checklist must continue onto another page, there are clear place keeping markers on both top and bottom of the continuation. Indentation should not be carried onto another page.
Checklist elements are visually distinct from each other. Navigation and place keeping structure are provided by sequential numbering of primary action steps. Landmarks such as page numbers are salient and always visible. Support is provided for indicating where you are in a checklist (especially if interrupted) and for identifying currently active steps. There are pointers to supporting information.
(9) Supporting Information
Understanding a checklist step may be supported with information explaining the basis for the step. This may include text, synoptics, and other technical information. Provision of such information helps less experienced pilots use the checklist in a more informed manner. It may also help minimize intentional non-compliance and help prevent operators from making inappropriate changes to the specified actions.
Supporting Information Guidelines
Statements of the high-level objective to be achieved by a checklist are presented. This information supports the pilot's evaluation of the success of the checklist.
Supporting information is located near the appropriate action step but not in such as way as to divide the sequence of steps. This provides supporting information (such as “amplified” information) in a way so that it does not interfere with checklist use. A very experienced pilot is able to quickly and efficiently complete the checklist with minimal distractions, but sufficient information is available for less experienced pilots to better understand the basis and meaning of checklist steps.
An indication may be provided for those steps for which supporting information is available. Since supporting information may not be available for every step, pilots can be provided with a visual indication, such as a symbol, to indicate when it is available. Information needed to perform a step or that contains warnings and cautions appear within the body of the checklist. Synoptics and circuit breaker diagrams may be included in the QRH.
(10) Operational Considerations
Checklists include information identifying the consequences of checklist use. This includes “Do not accomplish” statements and information about how other checklist are modified as a consequence of the current checklist or non-normal condition, e.g., modified NCs and operational constraints such as can't fly faster than, can't fly higher than, need longer runway, etc.
Operational Consideration Guidelines
This type of information is provided for all checklists where appropriate. Consequence information is presented following the checklist steps. Inoperative items and additional considerations information is provided such as what equipment may be needed for an approach, and inoperative equipment that may limit a particular kind of approach (CAT III), or other mission consequences that are relevant to the pilot. Where checklists are used prior to takeoff, these may include go/no-go criteria.
(11) Document Characteristics
Document characteristics refer to the features relating to the characteristics of the physical document, such as size, shape, page color, page texture, binding, etc.
Document Characteristics Guidelines
Pages may be white. White pages maximize the contrast between QRH elements and document background as well as color graphics. Pages are durable, resist glare, and spills. QRH binding preferably permits change pages to be easily included. The binding should be sturdy enough so that pages do not come apart when the QRH is dropped. Checklist typography should comply with NASA guidelines and standards.
The location of the QRH in the flight deck supports ready retrieval and physical support for use. The font size is at a minimum of 10 point, and 11 or 12 point is preferred. The longer size permits the use of larger font and may allow a checklist to reside on a single page rather than crossing multiple pages.
Philosophy and Assumptions
There are several assumptions underlying QRH philosophy of the present disclosure. Assumptions about flight crews and operational conduct that influence the design of the QRH will now be outlined.
Flight Crew Assumptions
One assumption about the flight crew is that aircraft pilots are qualified and trained in the aircraft. This assumes that pilots are trained in the aircraft, its systems, operation, and handling and have passed the minimum qualification standards. The level of detail of QRH instructions reflects this basis.
Another assumption is that aircrew behavior is guided by procedures. Because piloting is a complex activity, procedures are needed for normal and non-normal operations.
An addition assumption is that pilots have familiarity with the procedures through their training and experience. Checklists are needed as reminders of procedure actions.
A further assumption is that the aircrew may not be familiar with the specific non-normal checklist they are using. Because non-normal conditions are rare on modern aircrafts, a flight crew may not have used a non-normal checklist in a long time. Therefore, the QRH design should be intuitive.
Another assumption is that the flight crew has a basic level of English proficiency. This assumption recognizes that aircrafts are flown by flight crews who may not be native English speakers and that English proficiency varies. Thus, the QRH is written to reduce sentence complexity and make consistent use of words and terminology. This assumption also recognizes that reading proficiency is generally higher than oral proficiency among the pilot population world-wide.
A further assumption is that flight crews do not need explicit guidance in the checklist for the conduct of routine normal operational tasks. To reduce checklist complexity, explicit guidance for routine tasks a crew encounters in daily normal operations is not provided, such as Start APU, etc. Explicit guidance is provided in the checklist for any task that deviates from normal operational settings or sequence.
An additional assumption is that the flight crew is responsible for prioritizing their activities and sequence of checklist accomplishment. Generally assumes flight crews will prioritize their tasks in the following order: safety, passenger comfort, and efficiency.
Operations Assumptions
One operations assumption is that if possible, the QRH should remain onboard the aircraft and be unique to that aircraft model. This simplifies the QRH design and makes it compatible with aircraft-specific equipment. A paper version of the QRH may be issued to pilots for their personal use as a study guide. Operational versions of the QRH should remain on the aircraft.
Another operations assumption is that Normal and Non-normal Procedures and the QRH are an integral part of aircraft design. The QRH is part of the overall aircraft design. The location of the QRH supports ready retrieval and physical support for use. Tasks that rely on integrating actions and information across different interfaces are supported to the extent that they are consistent, e.g., similar working, labeling, use of coding, etc. The QRH is designed to support the flight crew's operation of the aircraft in normal and non-normal conditions.
A further operations assumption is that checklist action items vary in their time demands for completion. A limited set of actions must be performed immediately and therefore must be memorized (cannot rely on checklists). Others must be performed quickly and require immediate access. The remaining actions are performed when encountered in the checklist or are deferred. The design of the checklist reflects these dimensions of time.
An additional operations assumption is that checklist action items vary in their teamwork demands for completion. The kind of crew coordination required for checklist completion varies. The design of the checklist reflects this variation. Normal checklists typically follow the do-verify and challenge-response teamwork methods. Non-normal checklists typically follow the challenge-do-verify, read-and-do, and challenge-confirm methods.
Another operations assumption is that flying requires teamwork. Flying requires significant crew task coordination. At the simplest level, tasks are divided between the “pilot flying” (PF) and the “pilot monitoring” (PM). The flight deck is also divided into areas of responsibility to suggest an appropriate division of crew action between pilots. Thus the checklists are designed to support both of these paradigms.
Yet another operations assumption is that checklists do not guide the flight crew to trouble shoot non-normal conditions. In non-normal situations while flying, pilots manage the aircraft's configuration to ensure safety and the QRH does not address diagnostic and maintenance information. However the QRH may contain information that might help a flight crew confirm a non-normal condition.
In special operational situations, such as ETOPS (Extended Twin-Engine Operations or Extended Diversion Time Operations), additional information that supports diagnostic analysis may be provided. In rare cases where there is potential for the conduct of the checklist to not resolve the situation, additional systems configuration guidance may be provided in the QRH.
Checklists address single malfunctions and do not address situations involving multiple failures. In certain unrelated multiple failure situations, the flight crew may have to combine elements of more than one checklist and possibly make judgments about how to proceed. The pilot-in-command must assess the situation and use sound judgment to determine the safest course of action.
The QRH design also assumes flight deck information is correct unless there is conflicting information. Pilots are trained to assume the information presented by their flight deck displays is accurate and they generally do not need to verify that the QRH triggering conditions are valid. In some situations indicator lights are tested to verify suspected faults.
The pilot-in-command is the final authority for the operation of the aircraft. Both pilots, however, are responsible for the safe operation of the aircraft. Pilots must be aware that checklists cannot be created for all situations and are not intended to replace sound judgment. In some cases, deviation from checklists may (at the pilot-in-command's discretion) be necessary based on the unique situation of the aircraft.
In a non-normal condition, the pilot-in-command is expected to manage the flight situation. Research has shown (FAA/NTSB) that the incident and accident rate is lower when the pilot-in-command manages the non-normal situation.
In a non-normal condition, the flight crew is expected to utilize an appropriate level of automation that will aid the crew in workload management. Expects pilots will use automation as a tool for reducing crew workload under non-normal conditions.
The QRH design also assumes that flight crews do not need explicit guidance in the checklist for the conduct of routine normal operational tasks. To reduce checklist complexity, explicit guidance for routine tasks a crew encounters in daily normal operations is not provided, such as Start APU. Explicit guidance is provided in the checklist for any task that deviates from normal operational settings or sequence.
The QRH is designed to be a single-source reference document for in-flight operational use by the flight crew. The QRH contains checklists as well as any appropriate supporting information to aid the crew in checklist completion. It is not intended to contain training information.
The flight crew is expected to read every line in the checklist. Any unnecessary text is removed from the checklist. The checklist is to be accomplished as written.
The QRH is to be used as part of a flight operations book set. Expects operators to have other documents with supplementary information on training, systems, etc.
Checklist Steps
Checklist steps provide instructions that guide pilot actions. There are three different kinds of checklist steps: decision steps, navigation steps, and action steps. Checklist steps differ along dimensions of (1) time demands, (2) crew action required, and (3) teamwork involved in their accomplishment. In some cases, these differences are reflected in the format of the checklist item. In other cases, these differences may be transparent to the flight crew and only be applicable in the authoring of checklists and procedures.
(1) Time Demands
Recall steps are actions the crew performs from memory. There are some non-normal conditions that require an immediate response from the crew where crew action must be initiated without delay and without reference to a checklist. Both crewmembers systematically and without delay accomplish all recall items in their area of responsibility from memory. Recall steps are minimized in the QRH and limited to only those actions that require an immediate crew response. Recall steps should not require conditional reasoning by the crew. Clear criteria can be established for identifying which steps must be recall steps and which may be reference steps.
Immediate Versus Quick Reference Actions
Immediate action checklists include immediate actions and may include quick reference actions. Some immediate action steps are of such critical nature that they are accomplished by memory. Other quick action steps may be conducted with reference to an immediate action checklist if such an immediate action checklist is included in the QRH. The immediate action memory steps and the immediate reference steps are preferably presented in the front of the QRH, in checklists at the front of each system section, and/or on a separate quick reference card (QRC) if used. All immediate action steps are duplicated within their corresponding reference checklists.
Immediate actions are typically “those actions that must be performed so expeditiously that time is not available for a crewmember to refer to a manual or checklist.” However, if it can be demonstrated that the action may be taken safely by reference to a QRC or immediate action index then the action need not be conducted from memory.
Some non-normal conditions require an immediate response, where no time can be lost when responding even to a checklist. These are primarily conditions involving flight control problems (such as runaway stabilizer trim, etc.) or non-normal maneuvers (such as explosive decompression, etc.). There may also be some cases where the workload of both pilots is excessive and neither pilot can refer to the checklist or if the checklist was read could process the information.
Hasty action can create other problems or make the situation worse. A mistaken diagnosis of the condition may lead to the wrong response. For an engine-fire warning in flight a memory item procedure might dictate shutting down the engine immediately. But a fire warning might also result from a faulty warning system or engine bleed air leak. If the throttle lever is retarded the fire warning may cease especially in the case, for example, of a bleed air leak. On short final or in a power-critical situation it may be prudent to not secure the engine if no secondary indications of engine fire are observed.
Immediate Action Items describe information from Order 8400.10—Air Transportation Operations Inspector's Handbook Volume 3, Chapter 15, Section 1, 2079. The following provides the definition of “Immediate Action”: An action that must be taken in response to a non-routine event so quickly that reference to a checklist is not practical because of a potential loss of aircraft control, incapacitation of a crewmember, damage to or loss of an aircraft component or system—which would make continued safe flight improbable.
An immediate action is an action that must be accomplished so expeditiously (in order to avoid or stabilize a hazardous situation) that time is not available for a crewmember to refer to a manual or checklist. Crewmembers must be so familiar with these actions that they can perform them correctly and reliably from memory. Situations that require immediate action include, but are not limited to the following, imminent threat of crewmember incapacitation, imminent threat of loss of aircraft control, and imminent threat of destruction of a system or component which makes continued safety of the flight and subsequent landing improbable.
Under these criteria, a flight crew donning oxygen masks in response to a depressurization or turning off the fuel and ignition in case of a hot start are situations requiring mandatory immediate action items. The loss of thrust on a jet engine during cruise, however, would not normally require an immediate action item according to these criteria.
Certain situations that either require or appear to require immediate action have proven to be a stimulus for evoking incorrect and inappropriate flight crew actions. Therefore, immediate action items must be strictly limited to only those actions necessary to stabilize the situation.
Reference Action Steps
Reference steps are performed by reference to the checklist. They are initiated when encountered in the checklist. The crew is expected to accomplish the checklist steps as written and to read each line aloud.
Delayed Action Steps
Delayed steps are performed when a specified condition or parameter is met, e.g., time or parameter value, aircraft state, etc. These steps are initiated when encountered in the checklist and the specified criteria are satisfied.
Deferred Action Steps
Deferred steps are performed at some later time in the flight, when the appropriate time (such as landing or approach) is encountered, or are an on-going task for the duration of the flight. The accomplishment of these steps is typically tied to a particular phase or phases of flight.
(2) Crew Actions
Decision Steps
Decision steps provide instructions for evaluating conditions so the appropriate action can be selected. The outcome of the step(s) is a decision about a course of action. Decision steps always involve a choice between competing paths for action. Decision steps involving conditional logic are not conducted from memory. There are three kinds of decision steps.
One kind of decision step relates to observations about the state of the world that requires the crew to determine the applicable state (e.g., light is on versus light is off, etc.). These decision steps involve a choice between two or more discreet conditions or specific courses for crew action. Another kind of decision step relates to judgments on the part of the flight crew. Such a decision step may be to determine the course of action to follow (e.g., to continue the flight versus to land, etc.) or to make a judgment about the management of the situation.
The third kind of decision step relates to an observation or judgment about a single condition, where only the single condition requires crew action. In some cases, the alternative condition (e.g., wing anti-ice is not required, etc.) is not presented because no crew action is required. This philosophy and format reduces checklist complexity.
Navigation Steps
Navigation steps instruct the pilot to go to a particular step in the checklist, to another checklist, to supporting information, or to the end the checklist.
Action Steps
Action steps describe the monitoring, control, briefing, planning, and communication actions to be taken, e.g., instructions to perform physical steps (e.g., depress XYZ, etc.) and/or mental ones (e.g., “verify”, etc.). Action steps may also describe the objectives of those actions.
In general the kinds of actions required of the crew include, but are not limited to the following actions: flight deck control/switch movement, flight control manipulation, movement of a critical control (teamwork), monitoring (for a condition or parameter), activities the flight crew engages in, enter or manipulate data, brief, communicate, direct, and review information.
Action steps may take the form of instructions, commands, or statements depending on the kind of information, teamwork, and timeliness required to accomplish the action.
An exemplary format for recall steps (which is a type of action step) is shown in
Recall steps are preferably grouped within a red box or other graphic indicator, such as being preceded by a red dot as shown in
When an action is performed in routine normal operations, there is no need to specify explicit guidance unless the step is modified for the specific non-normal conditions. Crew action is slowed for critical control movements to ensure that confirmation is actually made. Confirm appears in italics to indicate it is spoken and helps ensure the other pilot is in the loop. Various embodiments add the word “Confirm” before the action for the actions outlined in FAA 8400.10 Document.
Procedural actions that require confirmation include the following actions resulting in the shutting down of an engine, actions resulting in the deactivation of flight controls, actions that if performed incorrectly (in the wrong sequence or at the wrong time) produce a catastrophic result even if the incorrect action is highly unlikely, actions where past experience or analysis has shown that there is a high probability for error or incorrect action, which may create a hazardous situation.
An emphasis on confirmation of critical control movement by both crew members should not reduce the emphasis on confirmation of all actions in a non-normal response.
Some checklist actions are activity-based and appear in sentence format, such as for example, enter or manipulate data, reactivate flight plan, brief, communicate, direct, notify flight attendants, review information, and refer to “Flight with Unreliable Airspeed” tables on page X. These formats represent non-specific flight crew activities.
(3) Team Work
Checklist steps also vary in their requirements for crew coordination.
Non-Normal Checklists
Challenge-Do-Verify Method: “The challenge-do-verify (CDV) method consists of a crewmember making a challenge before an action is initiated, taking the action, and then verifying the action item has been accomplished. The CDV method may be effective when one crewmember issues the challenge, and the second crewmember takes the action and responds to the first crewmember verifying that the action was taken. This method requires the checklist be accomplished methodically one item at a time in an unvarying sequence. The primary advantage of the CDV method is the deliberate and systematic manner in which each action item must be accomplished. The CDV method keeps all crewmembers involved, provides for concurrence from a second crewmember before an action is taken, and provides positive confirmation that the action was accomplished. The CDV method also enforces crew coordination, cross-checking, and verification, all of which aid the crewmember in overcoming the adverse effects of stress. The disadvantages of the CDV method are that it is rigid and inflexible, and that crewmembers cannot accomplish different tasks at the same time.
Actions that require the CDV method appear in the challenge-response format. Actions that do not require the CDV method appear as an instruction statement. Instructions are read aloud and are performed by the PM or PNF.
Normal Checklists
Do-Verify Method: The do-verify (DV) method consists of the checklist being accomplished in a variable sequence without a preliminary challenge. After all of the action items on the checklist have been completed, the checklist is then read while each item is verified. The DV method allows the flight crews to use flow patterns from memory to accomplish a series of actions quickly and efficiently. Each individual crewmember can work independently, which helps balance the workload between crew members. The DV method has a higher inherent risk of an item on the checklist being missed than does the CDV method. All normal checklist items appear in the challenge-response format.” (Reference: Paragraph 3-2201 of Order 8400.10—Air Transportation Operations Inspector's Handbook Volume 3, Chapter 15, Section 1, 2079).
QRH Format and Content Changes
An exemplary QRH format including content changes will be described according to one exemplary embodiment of the disclosure.
Document Characteristics
The document may be longer and slightly wider (e.g., eleven inches long and six inches wide, etc.). The binder should not break open when dropped. The paper should be white and durable. A minimum font size of ten points is preferably used.
Document Organization
In various embodiments, QRH introduction material may be removed and placed in another document, such as the FCTM (Flight Crew Training Manual). The performance tables should be integrated with the checklist where appropriate. The remaining tables will be moved to another manual available to the pilot. Normal checklists format will be consistent to the maximum extent practical with the non-normal formats. Normal checklists will be separate from the QRH and placed on a glare resistant, laminated card.
Organization of Checklists in the QRH
Checklists will be indexed by page number. Each checklist may have a tab that is labeled with the page number. There will be several grouping schemes for organizing the checklists and will appear in the following order: Immediate Action, System, Messages, Lights All checklists with memory steps will be grouped in the immediate action section. Grouping schemes are in the front of the QRH and are tabbed and labeled appropriately. All checklist grouping schemes will list checklists in alphabetical order. Global structure of the checklists is organization by system. Checklists are then sequenced in a task-oriented manner. All checklists will be cross-referenced in the indices. There will be no duplication of checklists. Messages or lights that do not have an associated checklist will be indicated as “crew awareness” in the indices. Immediate action index will include all checklists with recall steps. Index unannunciated checklists in their own section in the index. Normal checklists format may be consistent with the non-normal formats. Normal checklists will be separate from the QRH and placed on a glare resistant, laminated card. There may be some critical checklists on the QRH cover (e.g. passenger evacuation, etc.).
Checklist Characteristics and Criteria
The page number will appear in large bold type in the upper right and lower right corners of the page. Title format is the same as the current version. Checklist titles will be distinct and unambiguous. The checklist title will match the message or light as much as possible. There should be no combined checklists (e.g. engine fire should be separate from engine severe damage or separation). Checklists titles that are not messages or lights will appear in mixed case. Contextual information will be visually grouped under the title and set off from the steps. A graphic of the triggering cue (message or light) will be presented near the title. Additional contextual information may be needed to advise the crew or assist verification with specific content specified. Checklists will indicate the context of their accomplishment (ground vs. in-flight). Checklists should contain data tables or graphics when appropriate. The checklist format will be designed to facilitate the tasks in the specific checklist. Therefore, there may be several checklist formats in the QRH.
Modified normal checklists versus phase of flight preparation statements. Order of checklist steps should be consistent with flight operations, such as to direct the pilot to head the airplane in the direction of an airport before doing the rest of the steps, etc. The condition statement should include information that helps the crew verify the checklist, indicate other possible conditions that might be present or should be considered, etc. Simplify checklists whenever possible. Identify lights, messages, and other cues that should be used to verify the condition. Whenever possible checklists that reference another checklist should attempt to integrate the referenced checklist into the originating checklist (e.g., as shown for the AC Bus checklist (
Checklist Steps
Primary action and first-level steps are preferably numbered. Steps will be worded in simple precise language. When appropriate, a limited set of graphical elements should be included to rapidly convey important information. Present steps with only the information needed to accomplish the step. The brackets will go away. Additional information about a step may be referenced in a footnote. Decision, action, and navigation steps will be easily discriminated from each other. Support is needed when different steps in different checklists conflict. Positive wording will be used when possible and negatives will be identified (in bold) so they are salient. The flow of checklists and checklist steps should follow task sequence. Related steps will be visually grouped, and the use of shading may also be used. Recall steps will be minimized (or at least reduced). Recall steps will be identified with a distinctive format (e.g., red box, connecting lines, preceded by a red dot, or other suitable graphic indicator, etc.). The specific items to consider in the decision steps should be grouped together. Decision steps will be closed, as much as possible. Decision steps will be graphically linked. Action steps will be referenced or placed immediately underneath the decision step. Significant decision terms will be highlighted (and/or) in bold type. Identify single conditions (e.g., APU if available, If wing anti-ice is required, etc.). Identify all conditions in decision steps. Provide context markers in checklists (something that indicates the appropriate context for action).
Exemplary formats for action steps are shown in
An exemplary format for a delayed action, such as monitoring for a condition or parameter is shown in
Some checklist actions are activity-based and appear in sentence format, such as enter or manipulate data, reactivate flight plan, brief, communicate, direct, notify flight attendants, etc.
Action statements should be worded, formatted, and/or coded to indicate the style of crew interaction and communication needed (such as using italics to indicate spoken words with confirm added to critical control movements, etc.). Clear initiation criteria should be provided, such as a clear indication of when to start (e.g., when a condition or parameter is to be met). Temporal aspects of steps should be clearly indicated in the wording of the step, such as using words like after, when, phase of flight, etc. Clear termination criteria should be provided, such as providing a clear indication of when to stop, even if checklist is not complete.
Navigation steps should instruct the pilot to go to a particular step in the current procedure, to go to another procedure, or to end the procedure. (Name of checklist complete, Name of checklist complete except for deferred items, Name of checklist complete and go complete another checklist, “End” or an end of checklist symbology is used to indicate no more crew action is required although there may be additional notes to read or other considerations, etc.)
Cautions and Warnings
Cautions are co-located with the associated step. A yellow inverted triangle with an exclamation point is presented before the step and is connected to an explanation, such as shown in the exemplary formats. Caution statements that apply to the whole checklist or a whole condition appear in a yellow box. A similar format for warning will be used.
Supporting Information
Operational consequences will be organized at the end of the checklist. They provide information about functional system consequences (such as inoperative systems) and its affect on system or airplane operation resulting from the non-normal condition. There are also mission-level consequences that the crew must be made aware of for the remainder of the flight. These consequences will also be presented at the end of the checklist but will be separate from the system-level consequences. Considerations is a new category of information that identifies other tasks or activities the crew must perform as a result of the non-normal condition but is not part of conducting the checklist. This information could include information about inoperative equipment that may limit a particular kind of approach, instructions to continue monitoring for icing, etc. This info will appear after the operational consequences section and after the “checklist complete” statement. The considerations section may also be divided into phase of flight: considerations for descent, considerations for landing, etc.
Maneuvers
Non-normal maneuvers will include only those maneuvers that may be referenced. They will not contain instructions for normal maneuvers, only non-normal or infrequent maneuvers, e.g. single engine approaches.
Performance Data
There may be a section for performance tables that are referenced by several different checklists. This section should be kept small and usable. The performance tables will be integrated with the checklist where appropriate. The remaining tables will be moved to another manual available to the pilot. Tables that support multiple checklists may be referenced so we do not duplicate tables across checklists. Performance data should be in a simple and pilot friendly format.
Normal Checklist Philosophy and Design Guidelines
Safety
Checklists are designed to maximize safe operation of the airplane.
Structure
Checklist structure should facilitate efficient interaction between the pilots. Where practical, the format should also indicate the kind of crew interaction (who speaks and when). For training purposes, normal and non-normal checklist structure and formats should be the same where possible.
Interaction Style
Specify the crew interaction styles used for each checklist. For most normal checklists, the preferred method is the scan-flow procedure (i.e., do first, talk after). The verification is conducted by reading the checklist with the “challenge-response” checklist technique. Where practical, identify when crewmembers perform concurrent checks and when they perform sequential checks. No checklists are conducted silently. All checklists are spoken and follow the challenge-response teamwork technique.
Briefings
Checklists should contain items to confirm the accomplishment of crew briefings and provide redundant verification of critical items (e.g., flaps).
Titles
Titles of the normal checklists should directly correlate to the phase of flight in which they are conducted. E.g., the landing checklist should be titled “Before Landing” checklist.
Checklist Initiation
Provide guidelines about when a checklist should be initiated and by whom. Define clear “triggers” for when the checklist is to be initiated.
Sequence
Procedures are organized by phase of flight and written to match typical customer line operations. The sequence of items in a checklist should match the most common sequence of information flow into the flight deck.
Checklist Complete
Provide a “Checklist complete” statement or icon at the end of all checklists read aloud.
Interruptions
Design to be resilient to interruptions and distractions. Provide policy of when it should be started over. Include a guideline on when to avoid doing a checklist, to minimize interruptions.
Typography
Follow industry typography standards.
Checklist Length
Keep checklists associated with airplane transition to a movement phase of flight (i.e. Before Takeoff, Before Landing) as short as possible to: a) reduce crew workload and b) increase resiliency to interruptions.
Verification
Where possible, both the checklist reader and responder are responsible for visually verifying checklist items were properly set.
Multiple Flights
Some operations require checklists be run several times a day or only once a day. The design should be simple so that it is easy to support both kinds of flight operations.
Response
The checklist item response should reflect the flight deck cue or environmental cue the crew will use to identify/verify the action was properly conducted. These could range from the outcome of the action, the desired control position, the desired state of the system or airplane, or a combination of these. Ambiguous words like “As Required” or “Checked” or “Set” should be avoided where possible.
Quick Reference (QRH) Design Guidelines
Human Performance Model
Assumptions about flight crew competencies and conduct must be interpreted within the context of human performance. A key aspect of user-centered design is that to support skilled performance, the resources provided have to be compatible with the crews cognitive and information processing capabilities. In this section we will consider this perspective.
A commercial aircraft is a complex integration of hardware, software, and human components that work together to achieve mission goals of efficient and safe transportation. Crewmembers have defined responsibilities for their role in achieving the mission and perform tasks to achieve them. These tasks involve, among other things, interacting with other aspects of the system (hardware and software). This is accomplished through the user-system interface (USI).
The USI provides resources, such as alarms, displays, controls, and procedures the crew uses to perform their tasks. USI resources are organized into a flight deck layout and their use is affected by environmental conditions, such as lighting, temperature, and noise. These are important considerations in USI design.
Like any supervisory controller, the pilots' primary tasks involve several generic cognitive tasks.
Monitoring and Detection
Monitoring and detection refer to the activities involved in extracting information from the environment. Monitoring is checking the state of the aircraft to determine whether the systems are operating correctly; it can include checking parameters on flight deck displays, observing an unusual situation (like vibration or smoke), or obtaining reports from other crewmembers. Detection is the pilot's recognition that something is about to become non-normal or is non-normal.
Situation Assessment
When pilots observe indications of a non-normal occurrence, they try to construct a coherent, explanation for them. This cognitive activity may be called situation assessment and involves coordination between crew knowledge and experience, the external setting, and context. It is through the coordination of these that the crew develops an accurate understanding of the situation. These understandings may be dynamic and adaptable to new stimuli in the environment. Ideally, the crew has agreement on their individual assessments of the flight situation.
Action Response
Action Response refers to deciding upon a course of action to address a situation and then taking action. In general, response planning involves using a situation model to identify objectives (stabilize the airplane) and the transformations required to achieve them. In the absence of procedures, pilots generate alternative response plans, evaluate them, and select the most appropriate one to the current situation model. In some cases the crew may interact with the world to gain more information about the situation or to refine their understanding of the situation. These interactions may influence future actions.
The primary tasks of pilots also include crew communications and coordination with people and events outside the aircraft, like air traffic control, operator flight management centers, and airport ground operations.
Aircraft procedures and QRHs are an integral part of the flight deck and the crew's performance of primary tasks. Aircraft procedures are designed to support the crew by providing strategies based on detailed, “off-line” analyses of both normal and non-normal states. The procedures help bridge the gap between engineering and operations. The QRH supports several aspects of primary task performance.
The QRH supports monitoring by informing crews of the task relevant aircraft parameters.
The QRH supports situation assessment by (1) indicating the meaning of flight deck indications, (2) guiding the decision making process by providing decision steps that structure aircraft conditions using logical statements supporting the identification of a proper response plan to follow, (3) providing rationale for better understanding of action steps, and (4) providing information on the consequences of actions.
The QRH supports action response by providing pilots with step-by-step action statements to accomplish the objectives of the tasks.
Pilots work in a complex multitasking environment where many things compete for their attention. Since humans have limited attentional and cognitive resources, these resources have to be distributed to the activities they are engaged in. If one task requires a lot of resources, then not much may be available for other tasks.
To successfully perform these primary tasks, crews must perform secondary or “interface management tasks” such as physically manipulating a checklist, trying to determine what aspects of a checklist should be used in the current task, or accessing information in a checklist that is not readily available. In part, these tasks are necessitated by the fact that crews view only a small amount of information at any one time through their flight deck displays and checklist pages.
In many human performance domains, interface management demands have been found to be excessive under some circumstances and the additional workload may interfere with a crew's ability to perform their primary tasks (O'Hara and Brown, 2002). Two effects have been identified, namely resource-limited effect and data-limited effect.
Regarding the resource-limited effect, interface management tasks draw cognitive resources (e.g., attention) away from the primary tasks and performance declines because there are insufficient resources available for them. Primary task performance declines when too much attention is directed to secondary tasks.
With respect to the data-limited effect, primary tasks consume most of the cognitive resources leaving little for interface management performance. Since the primary tasks are dependent on interface management tasks to access the proper information, performance declines due to lack of information. Pilots manage workload by prioritizing their tasks into primary and secondary. Interface management tasks are not prioritized as highly as primary tasks and frequently are not performed. Crews will use several strategies to minimize interface management demands, such as using the currently viewed information rather than trying to retrieve the best information for the task.
Thus, interface management tasks may create barriers between crews and information. During periods of high workload, crews may decide to not access additional information because the retrieval effort may detract from the crew's primary task of handling the aircraft. Also, seeking new information may disrupt ongoing tasks or may interfere with current information being used. In some cases, crews may not access information because they do not know that it exists, such as failing to use a checklist for unannunciated situations.
In summary, while checklists support the general cognitive activities of crewmembers, their use may also add to overall workload and draw resources away from the primary tasks. As noted above, the management strategy adopted by pilots to cope with this added workload can impact performance of the primary tasks. The way a checklist is designed can greatly affect the secondary task workload it imposed. Therefore it is important to design the QRH to minimize secondary task workload.
In additional to effects associated with workload and attention management, checklist design can impact performance in other ways as well. There are certain design features that make the conduct of a checklist susceptible to error. When checklists have these features, they foster such design-induced errors. Some of the common design-induced errors are Misordered Action-Sequence Errors, Loss-of-Activation Errors, Capture Errors, Description Errors, and Action Errors.
Misordered action-sequence errors occur when steps within a sequence are skipped, reversed, and repeated. Competing tasks that create divided attention make pilots susceptible to this problem.
Loss-of-activation errors occur when attention is pulled away from the task to do something else and the pilot does not return to the checklist at all. The attention shift can disrupt memory of task status.
Capture errors occur when the pilot goes to take an action but accidentally completes a similar action. For example, if a pilot goes from an EICAS message to a procedure page, which contains several different procedures with very similar names, he may begin an incorrect checklist.
Description errors occur when the information used to initiate an action is ambiguous and leads to an incorrect action. For example, a pilot wants to begin a decent, but misinterprets a poorly worded instruction, and begins the decent too soon.
Action errors occur when an action is performed incorrectly.
Pilots may be more susceptible to these errors due to lack of familiarity, especially with NNCs (non-normal checklists). Even though QRHs are used by skilled pilots, the degree of pilot experience is variable, and even highly-experienced pilots may not be very experienced in the use of particular non-normal procedures. Checklists should be designed to minimize the occurrence of these common error forms.
With respect to the cognitive challenges of managing workload in complex operational environments, the goal of user-centered design is to provide flight deck interfaces that are easy to use and minimally distract crews from their primary tasks.
User interfaces are most effective when they are almost transparent to users. Transparency enables users to devote their complete attention to the primary tasks. To the extent that users must stop and think about how to use the interface, e.g., to navigate through a QRH to find data needed for checklist execution, attention is directed away from the primary tasks. At best, this can lead to frustration. The user's task has shifted from a primary task to figuring out how to use the interface. At worst, it can lead to error or abandonment of the primary task.
Thus, it is important to design the interface so that it supports the user to efficiently and safely perform their tasks. General principles for QRH design are high-level and their implementation in QRH design can lead to alternative design formats. They address the following aspects of QRH design: Accurately Represent the System, Support Crew Tasks, Meet Expectations, Minimize Secondary Tasks, Distractions, and Workload, Ensure Cognitive and Physical Compatibility, Design for Simplicity, Design for Standardization, Consistency, and Predictability, Design for Positive Guidance, Design for Discrimination, Design for Timeliness, Design for Appropriate Flexibility, Design for Tolerance to Error, and Ensure Health and Safety.
General Design Goals Based on Philosophy of Use
QRH features are designed to: Support skilled and trained flight crews in performing their primary tasks of monitoring and detection, situation assessment, response planning, and response implementation; Support teamwork; Minimize the imposition of secondary task workload; Accommodate varying experience levels of pilots and potentially less familiarity with non-normal conditions (NNCs) and checklists in comparison with normal conditions (NCs); Accommodate the multilingual background of users; Reflect human-centered design principles; and Minimize error and provide design features to detect errors where they occur.
The QRH is characterized in terms of the design components that make up its features and functions. QRH design will now be generally divided into the following six elements: (1) Checklist Indexing, (2) Immediate Actions, (3) Checklists, (4) Technical Data, (5) Document Characteristics, and (6) Navigation and Placekeeping Aids.
The QRH has an organizational structure that is part of the overall document design. Immediate actions may be placed in the first pages of the QRH and some may be even placed on the front covers (e.g.,
Each of the above design components is described below for exemplary embodiments of the disclosure. Other important design considerations involve the context within which the QRH will be used such as operational environment and relationship to other flight deck interfaces.
Operational environment generally refers to the design considerations that address the environmental conditions of use, such as lighting, glare, smoke, air mask, etc. Relevant factors have to be identified and the design should accommodate them.
Relationship of QRH to other flight deck interfaces generally refers to the QRH as being part of the overall aircraft design. These considerations address their relationship. The location of the QRH(s) should support ready retrieval and physical support for use. Tasks that rely on integrating actions and information across different interfaces are supported to the extent that they are consistent, e.g., similar working, labeling, use of coding, etc.
(1) Checklist Indexing
The QRH provides features to guide the pilot in selecting the proper checklist from an external triggering condition, such as a panel light, EICAS message, or pilot identification of an unannunciated condition. These features include tables of contents, light indices, alphabetical listing by system, etc.
(2) Immediate Actions
Immediate action checklists include immediate actions and may include quick reference actions. Some immediate action steps are of such critical nature that they are accomplished by memory. Other quick action steps may be conducted with reference to an immediate action checklist if such an immediate action checklist is included within the QRH. The immediate action memory steps and the quick or immediate reference steps may be presented in the front of the QRH or on a separate quick reference card (QRC). All immediate action steps are duplicated within their corresponding reference checklists.
(3) Checklists
Checklist identification: Checklists are identified through a checklist title and other information, such as triggering information and aircraft condition giving rise to triggers.
Checklist Steps: Checklist steps are instructions that guide pilot actions. There are three different kinds of steps: Decision, Action, and Navigation. Checklist steps differ along dimensions of crew action required, time demands, and teamwork involved in their accomplishment. In some cases these differences will be reflected in the format of the checklist item. In other cases these differences may be transparent to the flight crew and only be distinguishable for exposition of checklists and procedures.
The time demands for recall steps usually require recall steps to be initiated within 5 seconds. Recall steps are accomplished from memory.
Quick Action Reference is an action initiated within 15 seconds. These steps are performed with reference to an immediate action index.
Reference Action is an action initiated when encountered in the checklist.
Delayed Action steps are steps that are performed when some condition is satisfied, e.g., time or parameter value, state, altitude.
Deferred Action steps are steps that are performed at some later time in the flight, such as landing or approach.
Crew Actions—Decision Steps
Decision steps give instructions for evaluating conditions so the appropriate action can be selected from a predefined set. The decisions may involve conditional logic, i.e., where the actions are to be performed only if a specified set of conditions exists. Decision steps present conditional statements that help the pilot determine which checklist steps to use. The outcome of the step(s) is a decision about a course of action. As shown in
Crew Actions—Navigation Steps
As shown in
Crew Actions—Action Steps
Action steps describe the monitoring, control, briefing, planning, and communication actions to be taken, i.e., instructions to perform physical steps (e.g., depress XYZ, etc.) and mental ones (e.g., “verify”, etc.); they may also describe the objectives of those actions. In general the kinds of actions required of the crew include, but may not be limited to the following actions: move a physical control, monitor for condition or parameter, brief or communicate, review supporting information.
Action steps may take the form of instructions, commands, or statements depending on the kind of information, teamwork, and timeliness required to accomplish the action.
With respect to teamwork demands, steps differ in terms of the crew coordination and communication required to accomplish the step.
The Do-Verify (DV) method consists of the checklist being accomplished in a variable sequence without a preliminary challenge. After all of the action items on the checklist have been completed, the checklist is then read while each item is verified. The DV method allows the flight crew to use flow patterns from memory to accomplish a series of actions quickly and efficiently. Each individual crewmember can work independently which helps balance the workload between crewmembers. The DV method has a higher inherent risk of an item on the checklist being missed than does the CDV methods. (Reference: Paragraph 3-2201 of Order 8400.10—Air Transportation Operations Inspector's Handbook Volume 3, Chapter 15, Section 1, 2079). The verification should be accomplished using the challenge-response technique between crewmembers. The carrying out of memory items involves performing the action items from memory and then after the items are completed, verifying completion by checklist. The verification of memory items can be accomplished using the challenge-response technique between crewmembers.
The Challenge-Response (CR) can be used with normal checklists for checking to confirm that an action has already been correctly accomplished. The CR method is often used to verify that critical steps in procedure flows have been taken and the airplane is in proper configuration for the next phase of flight. The verification process in the DV style should be accomplished using the CR technique. For non-normal checklists the CR format is used for control movement action steps. Whenever possible the name of the control device or the label in the flight deck should be listed in the left margin and the action to be taken or the desired state should be listed in the right margin.
The Challenge-Do-Verify (CDV) method consists of a crewmember making a challenge before an action is initiated, taking the action, and then verifying that the action item has been accomplished. The CDV method is most effective when one crewmember issues the challenge and the second crewmember takes the action and responds to the first crewmember verifying that the action was taken. The method requires the checklist be accomplished methodically one item at a time in an unvarying sequence. The primary advantage is the deliberate and systematic manner in which each action item must be accomplished. The CDV method keeps all crewmembers involved, provides for concurrence before an action is taken, and provides positive confirmation that the action was accomplished. The disadvantages are that it is rigid and inflexible and that crewmembers cannot accomplish different tasks at the same time. The CDV method also enforces crew coordination, cross-checking, and verification, all of which aid the crewmember in overcoming the adverse effects of stress. (Reference: Paragraph 3-2201 of FAA 8400.10 document). The CDV method is for NNCs and applies to the specific action to be performed or the position of a switch or control should be moved to.
The read-do-call method consists of one crewmember reading aloud from the checklist and one pilot (depending on the area of responsibility) takes the action and calls that it is complete. This is step-by-step guidance through a checklist and does not rely on the crew's memory. This kind of teamwork is slow, deliberate, and accurate but can be susceptible to error if conduct is interrupted.
The challenge-confirm method consists of one crewmember making a challenge for a critical procedural item and then the second crewmember confirm prior to actuation. The FAA's 8400.10 document offers some guidance for this kind of teamwork. “Procedures which contain such critical procedural actions must clearly identify the critical actions and the crewmember who is responsible for giving the confirmation. The types of procedural actions that require this confirmation include the following: actions resulting in the shutting down of an engine; actions resulting in the deactivation of flight controls; actions that if performed incorrectly (in the wrong sequence or at the wrong time) produce a catastrophic result even if the incorrect action is not highly likely; actions where past experience or analysis has shown that there is a high probability for error or incorrect action and which creates a hazardous situation.” (Reference: Paragraph 2179 of FAA 8400.10 document).
Cautions
Cautions alert pilots to important preconditions, consequences of action steps, or consequences of the condition.
Operational Consequences
Checklists include information identifying the consequences of checklist use. This includes “Do not accomplish” statements and information about how other checklists should be modified as a consequence of the current checklist, e.g., modified NCs and operational constraints such as can't fly faster than, can't fly higher than, need longer runway.
Supporting Rationale
Understanding of a checklist step may be supported by information explaining the basis for the step. This may include text, synoptics, and other technical information. Provision of such information helps less experienced pilots to use the checklist in a more informed manner. It may also help minimize willful non-compliance and help prevent operators from making inappropriate changes to the specified actions. This information is commonly referred to as “amplified” information, and this amplified information may appear in brackets in the checklist or simply as text below the checklist step and is expected to be read aloud. A majority of operators have reported that current information is inadequate and needs further “amplification”.
Technical Data
Technical data that are integral to checklist use should be presented in the context of the checklist. This data provides information that is used to tailor checklist actions. Such information can be in the form of tables, graphs, and diagrams. This data should appear in a simplified, easy-to-use presentation. Additional technical data may appear on the normal checklist or in a separate data section at the back of the QRH or in the Operations Manual. The amount of technical data placed in the QRH should be minimal.
Navigation and Placekeeping Aids
These are the design features of the QRH that provide landmarks to indicate where the pilot is in the checklist (such as page numbers, step numbers, and headings, etc.) and features that facilitate the location of other information within and between checklists (such as tabs, arrows, etc.). Checklists may also include aids for placekeeping (marking where a pilot is so they can more easily return).
Organization of Checklists within the QRH
Organization refers to the physical arrangement of the checklists within the document. Most checklists today are arranged alphabetically within system.
Document Characteristics
These features relate to characteristics of the physical document, such as size, shape, page color, page texture, binding, etc.
Guidelines and Candidates for QRH Components
Exemplary guidelines or rules for the design of QRH components are identified in this section. In some cases, candidate concepts are presented that represent alternative ways of implementing the guidelines. The candidate concepts are sometimes presented following individual guidelines and sometimes at the end of the section. In the case of the latter, several guidelines may be reflected in the design.
These alternatives can be compared in the QRH Test and Evaluation program to select the features that best meet the usability objectives. Some guidelines are followed with “Rationale” statements or “Notes.” Rationale statements provide some justification or explanation of the guideline. Notes provide some considerations that could not be addressed at this time.
Checklist Selection
The QRH provides features to guide the pilot in selecting the proper checklist from an external triggering condition, such as a panel light, EICAS message, or pilot identification of an unannunciated condition. These features include tables of contents, light indices, categorization by system, etc.
Panel lights, EICAS message, and other triggers should have maximum (or at least heightened) discriminability to minimize (or at least reduce) the chance of going to the wrong checklist. One rationale for this is that since many messages in the flight deck have similar wording, pilots may access the wrong checklist. Enhancing the pilot's ability to discriminate between them will help minimize this error.
Unique numbers or letters can be assigned to flight deck information sources (e.g., in the lookup table or index) that are linked to checklists that are included in checklist identification information. For example, as indicated in
EICAS messages that do not have checklists should be coded in differently than those leading to checklists. A rationale for this is that pilots should immediately know which messages are associated with checklists and which are not. Providing this information will reduce needless access of the QRH when no checklist exists.
“Pilot awareness” checklists (carets) should be eliminated. A rationale for this is that carets require navigation, and pilots don't obtain any information once they access the appropriate checklist. If there is information useful to the pilot, then that information should be included in a checklist.
When separate EICAS messages send the pilot to the same checklist, a decision step should be provided to facilitate the determination of where in the checklist users should go for each particular message. In various embodiments, criteria are developed for when two checklists can be combined and when they should be kept separate. One criterion is the checklists can be combined when the condition leads to the same actions (the steps are the same). Another is that they can be combined when most of the steps are the same and the difference is easily represented by a decision step. Conversely, checklists should not be combined when complex decision steps are needed to guide pilots to the appropriate actions. They should also not be combined if a mistake can be dangerous. That is, if the pilot makes a mistake and performs the wrong step and that action significantly compromises flight safety.
The transition from triggering message to checklist should be as direct as possible with no additional cognitive analysis or interpretation required. A rationale for this is that pilots should not have to classify messages into systems and then look up the checklist in an alphabetical list by system. In some embodiments, checklist reference information is put directly in the trigger message so no lookup table is necessary. In the example below, the information in parenthesis is the unique QRH page reference to the appropriate procedure built directly into the EICAS message. When the message is read, the pilot can proceed directly to the checklist, thus bypassing the index.
This kind of change may be impractical for current airplanes without an ECL (Electronic Checklist). A retrofit electronic checklist application may later be developed and implemented for the current fleet.
When the actions required by different checklists or checklist steps conflict (e.g., set flaps at 20 degrees vs. 15 degrees, etc.), the checklist or other procedures should provide information to help pilots resolve the conflict.
When multiple triggers occur in close temporal proximity, pilots should be given information to help them choose the order in which checklists should be performed. A measure of support for this can be provided by using a prioritization coding scheme, similar to that used for EICAS messages. Pilots would be trained to complete higher priority checklists first. Color or some other scheme could be used to code checklist priority.
Checklists containing memory steps should be coded in the checklist selection tables and indices. A rationale for this is that coding this information will help alert the pilot to the existence of such steps if they somehow didn't realize these urgent steps had to be performed.
Immediate Actions
Immediate action memory steps should be minimized to only those actions that must be initiated within five seconds. Decision steps should not be memory steps. A rational for this is that these are the steps that must be accomplished to prevent crew incapacitation, airplane damage, or loss of control. Since these steps must be recalled from long-term memory and are performed without reference to a checklist, memory steps should only be required when a step must be accomplished before there is insufficient time to retrieve the QRH and access the checklist. Because relying on memory can be error prone, the number of such steps should be minimized. Also due to memory limitations, memory steps should not require reasoning about aircraft conditions, e.g., decision steps requiring conditional logical reasoning, etc.
If practical, immediate action steps should be presented in a convenient location that can be read within a few seconds. This is because immediate action steps must be almost immediately available once the crewmember has retrieved the QRH.
Any immediate action steps presented prior to referencing the full checklist should be repeated in the full checklist in a manner that visually sets them apart from non-memory steps. Clearly distinguishing memory steps from the rest of the checklist will facilitate pilots in starting at the right place in the checklist and not have to search for the proper step.
Checklists
Checklists are identified through a checklist title and other information, such as triggering information and aircraft condition giving rise to the triggers. Exemplary prototype concepts are provided following the guidelines.
Each procedure should have a distinctive title. To the greatest extent possible, the differences between titles should be maximized to minimize the chances of selecting the wrong checklist.
Page numbers should be prominently and saliently displayed near the checklist title. Any checklist with more than one page should begin on an even number. A rationale for this is that page numbers are used to transition from the checklist triggering condition to the checklist. Thus, the number should be highly salient for rapid and reliable viewing.
Contextual information needed to help ensure that the proper checklist is being used should be located near the title. At a minimum, that information should contain the specific triggering indicators and a statement of the underlying condition.
Checklist priority should be indicated as part of the contextual information. This is because checklist priority can aid in the determination of which checklist to use when more than one could be used. In addition, crews sometimes associate checklist length with priority. Providing priority information will eliminate that potential confusion.
Contextual information should be visually grouped and set off from the procedure steps. This will help pilots clearly distinguish contextual information from the procedure steps so that in case of time urgency the pilots can rapidly begin the checklist steps.
The prototype in
This prototype in
Another prototype is the same as the one in
Checklist Steps
Checklist steps are instructions that guide pilot actions. There are several different kinds of steps: Decision, action, and navigation. Prototype examples are presented for individual selected guidelines and at the end of the session to illustrate combinations of guidelines. Font sizing and adjusting font size can permit more information to be put on a page. Also proper font selection can facilitate readability and minimize errors.
The section is organized into the following subsections: General guidelines, immediate action steps, decision steps, reference action steps, and navigation steps.
General Guidance Regarding Checklist Steps
Each primary action step should be numbered. Steps should be worded in simple, precise language. Steps will be easier to follow if the amount of text is minimized. Vague language, like “as required,” should be made precise whenever possible. Responses to challenges should be full, specific and unequivocal, avoiding where possible the terms “as required” or “set”. Phases should be concise but understandable and unambiguous. Excessive brevity can result in checklists taking longer to read and understand.
Where possible, a limited set of graphic elements should be included to rapidly convey important information. Well chosen graphics are rapidly interpreted and will be less prone to error for non-native English speakers.
Present steps with only the information required to accomplish or understand the step. Checklist steps are the most important aspect of the QRH. Their presentation should be as clean and uncluttered as possible. Mixing other supporting information into the steps can create distractions that can more easily result in skipping or missing a step. Methods to ensure that pilots are aware of supporting information and are guided to it are addressed in other sections of this document.
Decision steps, action steps (including memory steps), and navigation steps should be easily discriminated from each other. Since the behaviors for the three types of steps are different, clearly distinguishing the types of steps can help ensure the proper behavior is accomplished.
Where checklist calls refer to a particular switch, light, lever or instrument, the entry must be the same as that used to identify it on the aircraft panel. These kinds of action steps should probably be put in the challenge-response format.
Decision Steps
The specific items to consider in the decision step should be grouped together. Decision steps give instructions for evaluating conditions so the appropriate action can be selected from a predefined set. Decision steps present conditional statements that help the pilot determine which checklist steps to use. Presenting all options together will facilitate evaluating the conditions.
An example of such grouping is presented in
Whenever possible, decision steps should be completely closed. Decision steps should be a closed system, so pilot has every possibility or combination of conditions is identified (all possible outcomes are addressed), e.g., in dual engine failure, provide guidance if the engines relight or not. Each should have a result, even if no further action is required.
Open-loop decision steps should be supported with additional information. In the case where the crew must make a judgment about which course of action to follow, operational consequences of each path should be presented to facilitate crew decision making.
Exploit crew perceptual processes. Whenever possible, the controls and indications that appear in the flight deck should be replicated in the checklist. See flaps example below.
Where possible, declarative statements of conditions should be presented rather than using conditional operators. “If . . . , then . . . ” statements are difficult for native English speakers to reason about. They can be very error prone for non-native English speakers.
Significant decision terms should be highlighted. Keep the use of these terms to a minimum whenever possible, including the use of such terms as “and” and “or.”
The outcome of the decision step(s) should be either navigation to the proper part of the checklist or to another checklist or to an agreed upon course of action.
Action Steps
Action statements should be worded, formatted, or coded to indicate the style of crew interaction and communication needed. Teamwork differences should be presented using alternative syntactical forms for the different teamwork styles required. However, the division of labor (e.g., pilot flying/pilot monitoring) may not be coded since the allocation of crew responsibility is based on the practices of the operator.
Clear initiation criteria should be provided (clear indication of when to start). Clear termination criteria should be provided (clear indication of when to stop, even if checklist is not complete). Temporal aspects of steps should be clearly indicated in the wording of the step, which user does now, which later, which continuous, and which deferred.
Steps can reflect the need to take action such as “immediate action memory” steps (e.g., less than five seconds)—these are the memory steps; “immediate action reference” steps (e.g., less than fifteen seconds); “reference” steps—steps that are performed when encountered in the procedure; “delayed” steps that are performed when some condition is satisfied (e.g., time or parameter value, etc.); “deferred” steps are deferred and performed when a predefined state/condition exists.
Important actions, like setting flaps, should be highlighted. All keywords need to be salient. Related steps should be visually grouped.
Navigation Steps
Navigation steps should instruct the pilot to go to a particular step in the current procedure, to go to another procedure, or to end the procedure. In the first example prototype in
In the second example prototype in
QRHs may also use arrows and lines to accomplish essentially the same thing. The example prototype in
An alternative to the use of lines, using only symbols is presented in
Cautions
Cautions alert pilots to important preconditions or consequences of action steps. Cautions should be highly salient. Since high salience is needed for cautions, color or distinctive symbology should be used rather than just font coding or other less salient feature. The discussion in the prototype section addresses the choice between them.
Cautions should be collocated with the appropriate step. This will help ensure that the content of the caution will be read when needed.
Where appropriate, information should be provided as to whether the caution applies prior or after the relevant step. This will help ensure that pilots know when to read the caution with respect to the step action.
Several exemplary different approaches to coding of cautions including using color (e.g., yellow, etc.) or a symbol (e.g., international alert symbol, etc) are presented in
Technical Data
Checklists include technical data that are integral to checklist use. This data provides information that is used to tailor checklist actions. Such information can be in the form of tables, graphs, and diagrams.
Information should be organized by task and checklist step. The information should be only as precise as needed by the task (over precision can add to complexity, time to use, and chances of error). Table and graph formatting should be designed to support visual search and readability. Technical data should be located near the appropriate action step but not in such as way as to divide the sequence of steps. Locating data near the steps reduces the need for pilots to have to navigate to it. This data is not located on the same page as the checklist steps so as to not separate sequential steps by too much information. To maintain awareness of where the checklist is going, it is important to keep steps relatively close together.
Visual aids should be used to assist pilots in locating supporting technical data. The prototype in
The alternative prototype in
Information on Supporting Rationale
Understanding of a checklist step may be supported by information explaining the basis for the step. This may include text, synoptics, and other technical information. Provision of such information helps less experienced pilots to use the checklist in a more informed manner. It may also help minimize willful non-compliance and help prevent operators from making inappropriate changes to the specified actions.
Statements of the high-level objective to be achieved by a checklist should be presented. This information supports the pilot's evaluation of the success of the checklist.
Supporting information should be located near the appropriate action step but not in such as way as to divide the sequence of steps. The supporting information (such as “amplified” information) should be provided in a way so that it does not interfere with checklist use. Very experienced pilots should be able to quickly and efficiently complete the checklist with minimal distractions, yet sufficient information should be available for less experienced pilots to better understand the basis and meaning of checklist steps.
An indication should be provided for those steps for which supporting information is available. Since supporting information may not be available for every step, pilots should be provided with a visual indication, such as a symbol, to indicate when it is available. See prototype examples above. Similar techniques should be used to present this information. Checklist steps should be kept clean and minimal as possible, thus this info can be placed somewhere else.
Operational Consequences
Checklists include information identifying the consequences of checklist use. This includes “Do not accomplish” statements and information about how other checklist should be modified as a consequence of the current checklist, e.g., modified NCs and operational constraints such as can't fly faster than, can't fly higher than, need longer runway.
This type of information should be provided for all checklists where appropriate. Where checklists are used prior to takeoff, “go/no-go” criteria may also be provided. Consequence information should be presented following the checklist steps, but before the “Checklist Complete” information.
Navigation and Placekeeping Aids
These are the design features of the QRH that provide landmarks to indicate where the pilot is in the checklist (such as page numbers, step numbers, and headings, etc.) and features that facilitate the location of other information within and between checklists (such as tabs, arrows, etc.). Checklists may also include aids for placekeeping (such as marking where a pilot is so they can more easily return, etc.). Prototypes of many of these features were presented earlier.
If possible, page numbers should be visible when the pilot is in the front of the QRH. Pilots navigate from the index to the proper checklist using page numbers.
Tabs with page numbers can also be put on the top of each page or possibly every five pages or so. Page numbers should be salient and always visible on each QRH page.
Support should be provided for marking the location of a needed checklist or other information. If a pilot leaves the checklist to do something else and wants to return to a particular location, marking will facilitate the transition. This can be accomplished in several ways. First, one or more “ribbon-type” bookmarks could be attached to the QRH binding. Pilots could use them as needed, to mark the location of a checklist or other supporting information. Another approach is to provide foldout tabs that can be opened. When open, the tabs are visible.
Support should be provided for identifying currently active steps. Visual aids and guidance should be provided when a checklist step directs the pilot's attention to another part of the checklist or supporting information.
Checklists that continue from one page to the next should provide markings on both top and bottom of the continuation.
Organization of Checklists within the QRH
Organization refers to the physical arrangement of the checklists within the document. Currently many operators arrange them alphabetically within the system.
Checklists should be organized to minimize the need for navigation through the QRH. The current organization can lead to errors of selecting a checklist with similar title. It also requires a lot of navigation when performing tasks. A task-based organization may be preferable so that checklists typically used together of which commonly follow each other can be located together.
Combining lots of things into one checklist should be avoided. Combining many situations into one checklist makes the checklist long and requires conditional statements. It is better to have more short checklists without conditionals.
Where possible, checklists should address less than worse-case scenarios. NC checklists and NNC checklists should be separated into two documents. Creating two documents will make each documents smaller, easier to navigate, and easier to manipulate.
Document Characteristics
These features relate to characteristics of the physical document, such as size, shape, page color, page texture, binding, etc. Pages should be white. White pages will maximize the contrast between QRH elements and document background.
Pages should be durable. QRH binding should permit change pages to be easily included. Binding should be sturdy enough so that pages do not come apart when the QRH is dropped.
According to an embodiment and generally referring to
The QRH can also provide immediate access to checklists that contain action steps that must be performed without delay. So they are easy to locate and use, immediate action or quick action checklists can be placed in the front of the QRH, in the front of their corresponding system sections, and/or they can be placed on the QRH covers. For example,
As best seen in reference to
Referring generally to
Referring generally to
As best seen in reference to
Referring next to
Referring now to
As best seen in
Referring next to
As best seen in
Referring generally to
Referring next to
Referring generally to
As best seen in reference to
Referring generally to
Referring to
Referring generally to
With reference now to
Also shown in
The checklist format shown in
As shown in
Also shown in
With reference now to
Various embodiments include digital or electronic data for a QRH, which may be provided in XML (extensible markup language), Adobe's Framemaker, HTML (hypertext markup language), PDF (portable document format), etc. The digital or electronic version of the QRH may reside on any of a wide range of computer or machine readable media.
The digital or electronic version of the QRH may allow the user to electronically access the material, for example, while using an electronic flight bag (EFB) or other computing device. Additionally, or alternatively, the electronic QRH version may allow the user to print out the electronic QRH to create a hard copy that can then be accessed and reviewed by a user.
Various embodiments can also include a user interface that allows the user to enter data for the QRH, such as the checklists and the checklist steps. In this exemplary manner, the user would be able to modify the content as necessary to meet the user's airline operational needs. The user could then print out the QRH having the user-entered data. When the QRH is printed, the print version may include at least one checklist having a format corresponding to any one of the formats described and shown herein, such as the checklist format shown in any one of
Various embodiments include a machine-readable medium for use with a processor having a memory. The machine-readable medium includes instructions to cause a processor to generate a hard copy or print copy of a QRH having at least one checklist in a format corresponding to any one of the formats described and shown herein, such as the checklist format shown in any one of
In various embodiments, the digital or electronic version of the QRH can be coded such that the QRH can be printed in color, grey scale, or black and white. In such embodiments, items within one or more of the QRH checklists may be “double coded” with graphic indicators (e.g., inclusion within a rectangular box, etc.) and with color.
According to one embodiment of the present disclosure, a digital or electronic version of a QRH includes sequentially numbered pages on which are presented checklists. An alphabetized immediate or quick action index is provided on at least one of the pages and differentiated from the checklists. At least one checklist can be an immediate or quick action checklist, which includes at least one recall step differentiated by inclusion within a substantially rectangular box or other distinctive graphic indication.
According to another embodiment of the present disclosure, a digital or electronic version of a QRH includes a plurality of checklists that are organized within the electronic QRH by listing the checklists within a corresponding one of a plurality of grouping schemes. The grouping schemes include Immediate Action, Systems, EICAS Messages, and Lights. The electronic QRH can also include differentiating criteria for decisions steps, action steps, and navigation steps within the checklists to thereby enable a user to readily discriminate the decision steps, action steps, and navigation steps from each other. The electronic QRH can also include visually groupings of related steps within a checklist.
In another exemplary implementation, a digital or electronic version of a QRH includes additional operational considerations that are listed after an indicator that a checklist is complete. The additional operational considerations can provide planning information and mission consequences the crew may wish to perform due to a non-normal condition but which are not a required part of conducting the checklist.
In a further exemplary implementation, a digital or electronic QRH includes a list of operational consequences associated with a checklist near the end of a checklist but before an indicator that the checklist is complete. The operational consequences of inoperative items can provide information to the user about consequences resulting from a non-normal condition.
While various exemplary embodiments have been described, those skilled in the art will recognize modifications or variations which might be made without departing from the inventive concept. The examples illustrate the disclosure and are not intended to limit it.
This application is a divisional application of U.S. patent application Ser. No. 11/242,679, filed Oct. 4, 2005, which is a continuation-in-part of U.S. patent application Ser. No. 10/938,393, filed on Sep. 10, 2004, which, in turn, claims the benefit of U.S. Provisional Application No. 60/502,135, filed on Sep. 11, 2003. The disclosures of the above applications are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60502135 | Sep 2003 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11242679 | Oct 2005 | US |
| Child | 12783126 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10938393 | Sep 2004 | US |
| Child | 11242679 | US |
