Patent Application
20050057035
The present invention 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.
According to a preferred embodiment of the present invention, a style guide and formatting methods for pilot quick reference handbooks of the present invention includes
According to another preferred embodiment of the present invention.
The features, functions, and advantages can be achieved independently in various embodiments of the present inventions or may be combined in yet other embodiments.
The present invention 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 the exemplary embodiment(s) is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses.
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.
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 performing 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, namely, monitoring and detection, situation assessment, and action response. 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. Monitoring 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.
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.
Misordered 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 ICAS message to a procedure page, which contains several different procedures with very similar names, the pilot 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 non-normal conditions (NNCs). 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 non-normal procedures.
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.
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:
General principles for QRH design are described below that address at least one or more of the following aspects of QRH design:
The present criteria for designing a quick reference handbook (QRH) reflects 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 an improved, user-centered QRHs, the present invention provides at least one or more of the following advantages:
1) Reduces 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.
2) Improves operator understanding of checklists and information in the QRH.
3) Further standardizes 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.
4) The QRH for 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 topics:
5) 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.
6) 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.
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 a 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.
Organization of Checklists within the QRH
Organization refers to the physical arrangement of the checklists within the document. Currently, checklists are arranged alphabetically within the system. 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 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 is avoided. Combining many situations into one checklist makes the checklist long and requires conditionals. It is better to have shorter checklists without conditionals.
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 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 discriminability to minimize 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 them helps minimize 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.
Eliminate “crew awareness” checklists (Carets). 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), 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. Prototype/Exemplary Concept Provide several short indexes: Messages, Lights, Unannunciated, System Name. For the non-EICAS aircrafts there are 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.
Provide immediate access to checklists that contain action steps that must be performed without delay. Place immediate action checklists in the front of the QRH or on the QRH covers so they are easy to locate and use. Immediate action checklists in the front of the QRH helps reduce the need for excessive memory items. Time critical checklists are easier to locate if they are in the front of the book where they are readily accessible. These immediate action checklists are duplicated in the body of the checklist before any subsequent checklist items. This provides continuity from immediate action checklist to the additional checklist steps.
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.
Guidelines
Each checklist has a distinctive unambiguous title and whenever possible the title will match the cue. (EICAS message or discreet light). To the greatest extent possible, the differences between titles are maximized to minimize the chances of selecting the wrong checklist.
Page numbers are prominently and saliently displayed near the checklist title. Page numbers are used to transition from the checklist triggering condition to the checklist. Thus the number are highly salient for rapid and reliable viewing.
Contextual information needed to help ensure that the proper checklist is being used is located near the title. At a minimum that information contains the specific triggering indicators and a statement of the underlying condition.
Contextual information is visually grouped and set off from the procedure steps. Pilots are be able 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 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 the correct checklist has been found. These is color coded to match their appearance in the flight deck.
Checklist Steps
Checklist steps are instructions that guide pilot actions. There are several different kinds of steps: decision, action, and navigation. Checklist action steps will 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, 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
Each step is numbered. First-level checklist action steps are numbered to assist with place keeping. 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,” has been made precise.
Where possible, graphic elements are 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 without other information. 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, action (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 is not a problem, because of appropriate font size and style (e.g., no font size less than 10 pts).
Support is needed when different steps in different checklists conflict (for example: set flaps at 20 degrees vs. 15 degrees).
Use positive wording of action steps when possible and identify negatives so they are salient.
The flow of checklists and checklist steps follows flight task sequence.
Recall Steps
Recall steps are minimized 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 insufficient time to retrieve the QRH and access the checklist. Because relying on memory can be error prone, the number of such steps are 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, i.e., the pilot does not have to access the complete checklist to view the memory steps. Prototype/Exemplary Concept Recall steps can be presented on the QRH covers or in the first few pages. Guidance from the end of the presentation of recall steps to the full checklist is provided with clear reference to the appropriate page number. Recall steps are 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.
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 has a positive 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 difficult for native English speakers to reason about. They can be very error prone for non-native English speakers. 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 worded, formatted, or coded to indicate the style of crew interaction and communication needed as follows:
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.
Cautions
Cautions alert pilots to important preconditions or consequences of action steps. Cautions are highly salient. Since high salience is needed for cautions, color or distinctive symbology is preferably used rather than 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 is used to discriminate between them. Locate these near the appropriate action step so pilots are likely to read them when needed.
Technical Data
Checklists 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 the operations 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.
Guidelines
Information is organized by task and checklist step. The information is only as precise as needed by the task (over precision adds 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.
Navigation Aids and Placekeeping
These are the design features of the QRH that provide landmarks to indicate where the pilot is in the checklist (such as page numbers and headings) 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).
Guidelines
Page numbers are 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” 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 will 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 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.
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.
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, yet sufficient information is available for less experienced pilots to better understand the basis and meaning of checklist steps.
An indication is provided for those steps for which supporting information is available. Since supporting information may not be available for every step, pilots are provided with a visual indication, such as a symbol, to indicate when it is available. Information that is needed to perform a step or that contains warnings and cautions appears within the body of the checklist. Synoptics and circuit breaker diagrams are included in the back of the QRH.
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, higher than, need longer runway.
Guidelines
This type of information is provided for all checklists where appropriate. Where checklists are used prior to takeoff, “go/no-go” criteria is provided. Consequence information is presented following the checklist steps, but before the “Checklist Complete” information. Provide information about what equipment is needed for each approach and indicate inoperative equipment that may limit a particular kind of approach (CAT III). Where checklists are used prior to takeoff, these include go/no-go criteria.
Document Characteristics
These features relate to characteristics of the physical document, such as size, shape, page color, page texture, binding, etc.
Guidelines
Pages are 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 permits change pages to be easily included. Binding is sturdy enough so that pages do not come apart when the QRH is dropped. The introduction to the QRH is removed and placed in the flight-crew training manual. Checklist typography will 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 10point, and 11 or 12 point is preferred. The longer size page is preferred over the current Jepp size. The longer size permits the use of larger font and allows more checklists to reside on a single page rather than crossing multiple pages.
Philosophy and Assumptions
There are several assumptions underlying QRH philosophy of the present invention. Assumptions about flight crews and operational conduct that influence the design of the QRH are herein outlined.
Flight Crew Assumptions
Aircraft pilots are qualified and trained in the aircraft. 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.
Aircrew behavior is guided by procedures. Because piloting is a complex activity, procedures are needed for normal and non-normal operations.
Pilots have familiarity with the procedures through their training and experience. Checklists are needed as reminders of procedure actions.
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 design must be intuitive.
Procedures assume a basic level of English proficiency. Recognizes 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. Also recognizes that reading proficiency is generally higher than oral proficiency among the pilot population world-wide.
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, etc. Explicit guidance is provided in the checklist for any task that deviates from normal operational settings or sequence, such as Start APU On Bus, etc.
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
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.
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.
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.
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.
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. [Instead of using PM terminology, an active monitoring philosophy is used that clearly defines the roles of each pilot, particularly the role of the PNF.]
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, 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 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. However, both pilots 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 while the second-in-command flies the aircraft. 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.
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, such as Start APU On Bus.
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 does not 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 FCTM, 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 Time demands, Crew action required, and 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.
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 the area of responsibility from memory. Recall steps are minimized in the QRH and limited to only those actions that require an immediate crew response. No recall steps will require conditional reasoning by the crew. Clear criteria can be established for identifying which steps must be recall 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. The immediate action memory steps and the immediate reference steps are preferably 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.
POI's may approve an operator's proposal to replace immediate action items in an AFM or RFM procedure with challenge-do-verify checklist procedures in a CFM provided the operator shows compliance with the criteria in this paragraph and also demonstrates an equivalent level of safety through validation tests.
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 (runaway stabilizer trim) or non-normal maneuvers (such as explosive decompression). 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 instantly. But a fire warning may result from faulty warning systems and bleed air leaks. If the throttle lever is retarded the fire warning may cease especially in the case 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. POIs must ensure that immediate action situations are included in an operator's AFM, RFM, or CFM, as appropriate. Situations that require immediate action include, but are not limited to the following:
Under this criteria, a flightcrew 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 this criteria.
POIs must ensure that immediate action items are explicitly identified as such in an operator's CFM. It is not acceptable for immediate action items to be hidden (not specifically identified as an immediate action) in procedures or checklists.
Certain situations that either require or appear to require immediate action have proven to be a stimulus for evoking incorrect and inappropriate flightcrew actions. Therefore, immediate action items must be strictly limited to only those actions necessary to stabilize the situation. POIs must ensure that all remaining actions are accomplished by “challenge do verify” (CDV) checklists.
POIs may approve an operator's proposal to replace immediate action items in an AFM or RFM procedure with challenge do verify (CDV) checklist procedures in a CFM, provided the operator shows compliance with the criteria in this paragraph and also demonstrates an equivalent level of safety through validation tests.
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.
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 never conducted from memory.
There are three kinds of decision steps:
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, 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 are not limited to the following actions:
An Exemplary format for Recall Steps are shown below. Recall steps can be grouped with a red box. Recall steps are distinguished from other action steps. The box format is consistent with current QRH format. An alternative format is the current format of a single black box.
Proposed Format for Recall Steps:
Recall steps are preferably grouped within a red box. Recall steps are distinguished from other action steps. The box format is consistent with the current QRH format. An alternative format is the current format of a single black box.
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.
Flight Control Manipulation
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. We propose the addition of the word “Confirm” before the action for the actions outlines in FAA 8400.10 Document:
Procedural actions that require confirmation include the following:
There is some concern that an emphasis on these actions will reduce the emphasis on confirmation of all actions in a non-normal response, that is, confirmation of critical control movement by both crew members.
Some checklist actions are activity-based and appear in sentence format.
Brief, communicate, direct
Review information
These formats represent non-specific flight crew activities.
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” can appear in italics to indicate it is spoken and helps ensure the other pilot is in the loop. The addition of the word “Confirm” is preferably done before for the actions outlined in FAA 8400.10 Document:
Procedural actions that require confirmation include the following:
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; Review information; and Refer to “Flight with Unreliable Airspeed” tables on page X. These formats represent non-specific flight crew activities
Teamwork
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 maybe 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 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 rigid and inflexible and that crewmembers cannot accomplish different tasks at the same time. (adapted from FAA 8400.10)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 again 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.
The document will be longer and slightly wider (11 inches long, 6 inches wide). The binder will be replaced with some better binder that does not break open when dropped (FTP). The paper will be white. The paper will be durable. A minimum font size of 10 points is used.
The introduction will be removed and placed in the FCTM. The performance tables will be integrated with the checklist where appropriate. The remaining tables will be moved to the OM. Normal checklists format will be consistent with the non-normal formats. Normal checklists will be separate from the QRH and placed on a glare resistant, laminated card.
Checklists will be indexed by page number. Each checklist will 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 in their entirety. Provide an unannunciated matrix to aide condition identification. Cross-referencing of the checklists in indexes. Format of lights index, which lights are needed and not needed in the index. Index unannunciated checklists in their own section in the index. Normal checklists format will 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).
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 will be no combined checklists (e.g. engine fire will 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 will 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. Identify new checklists that are needed. Create checklists for ground operations. Identify follow-up maneuver checklists.
Modified normal checklists versus phase of flight preparation statements. Order of checklist steps (to be consistent with flight operations, to direct the pilot to do point the nose in the direction of an airport before doing the rest of the steps, etc.). Replacing the condition statement with information there that helps the crew verify the checklist, indicate other possible conditions that might be present or should be considered, etc. Simplify checklists. 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 and the cabin altitude checklist).
Steps are numbered. Steps will be worded in simple precise language. When appropriate, 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, the use of shading may also be used. Recall steps will be minimized. Recall steps will be identified with a distinctive format (red box or line). 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 (APU if available, If wing anti-ice is required). Identify all conditions in decision steps. Context markers in checklists (something that indicates the appropriate context for action). Criteria for action steps that require supporting information. Simplify checklist steps.
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.
Movement of a critical control (teamwork/qualified)
Delayed action (Monitoring for a condition or parameter. The conditions in this step must be met before taking the action). The keyword is presented in bold, for added salience we could bold the whole criteria.
Some checklist actions are activity-based and appear in sentence format.
Enter or manipulate data; Reactivate flight plan;
Brief, communicate, direct; Notify flight attendants
Action statements should be worded, formatted, or coded to indicate the style of crew interaction and communication needed (italics indicate spoken words, confirm added to critical control movements). Clear initiation criteria should be provided, i.e. clear indication of when to start (condition or parameter to be met). Temporal aspects of steps should be clearly indicated in the wording of the step. (after, when, phase of flight). Clear termination criteria should be provided (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” is used to indicate no more crew action is required but there are additional notes to read or other considerations, etc.)
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, see 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.
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.
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.
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 the OM. Tables that support multiple checklists may be referenced so we do not duplicate tables across checklists. Performance data must be simplified and re-formatted.
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 normal checklists, the preferred method is the “flow-verify” 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.
Naming Convention. Use “Pilot Monitoring” (PM) and “Pilot Flying” (PF) when xxx. Use “Captain” and “First Officer” (FO) when xxx. Use “Left” and “Right” when xxx. Use X/X xxx.
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 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.
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:
Monitoring—by informing crews of the task relevant aircraft parameters.
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 support 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.
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 use 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:
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.
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. 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 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. 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—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—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—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 ICAS message to a procedure page, which contains several different procedures with very similar names, he may begin an incorrect checklist.
Description Error—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—This occurs when an action is performed incorrectly.
Pilots may be more susceptible to these errors due to lack of familiarity, especially with NNCs (non-normal conditions). 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 non-normal procedures. Checklist 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:
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 potential 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; 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. For the purposes of this document, QRH design will be divided into the following elements:
The QRH has an organizational structure that is part of the overall document design. Immediate actions are placed in the first pages of the QRH and some may be even placed on the front and back covers. Checklist indexes follow the immediate actions. The checklists that follow and are indexed by page number. Supplementary Technical Data that is not included within a checklist is placed in the back of the QRH. A section for Revision data and dates is also provided at the back of the QRH.
Each of the above design components is described below. Other important design considerations involve the context within which the QRH will be used such as:
Operational environment. These are 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. The QRH is 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.
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.
Immediate action checklists include immediate actions and may include immediate reference actions. Some immediate action steps are of such critical nature that they are accomplished by memory. Other immediate action steps may be conducted with reference to an immediate action checklist. The immediate action memory steps and the immediate reference steps are 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.
8400.10 Doc.
“POI's may approve an operator's proposal to replace immediate action items in an AFM or RFM procedure with challenge-do-verify checklist procedures in a CFM provided the operator shows compliance with the criteria in this paragraph and also demonstrates an equivalent level of safety through validation tests.” Paragraph 2177 D.
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.
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.
Time Demands: Recall steps: (initiated and accomplished within 5 seconds), these steps are accomplished from memory.
Quick Action Reference: (initiated and accomplished within 15 seconds). These steps are performed with reference to an immediate action index.
Reference Action: (initiated when encountered in the checklist).
Delayed Action: steps that are performed when some condition is satisfied, e.g., time or parameter value, state, altitude
Deferred Action: steps that are performed at some later time in the flight, such as landing or approach
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. There are two kinds of decision steps. One involves an observation about the state of the world and requires the crew to determine the applicable state (light is on versus light is off). The other kind of decision step is open-ended and involves a judgment on the part of the flight crew. Such a decision step may be to determine the course of action to follow (to continue the flight versus to land, etc) or to make a judgment about the management of the situation. Decision steps always involve a choice between competing action paths. Decision steps involving conditional logic are never conducted from memory.
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. The only kind of teamwork required is for the pilot monitoring to announce that the checklist is complete.
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:
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.
Teamwork demands—steps differ in terms of the crew coordination and communication required to accomplish the step.
Do-Verify—“The DV methods 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 methods has a higher inherent risk of an item on the checklist being missed than does the CDV methods”. 8400.10 paragraph 3-2201. 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, verify completion by checklist. The verification of memory items can be accomplished using the challenge-response technique between crewmembers.
Challenge-Response—In normal checklists, CR is used for checking to confirm that an action has already been correctly accomplished. This 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.
Challenge-Do-Verify—“The 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.” 8400-10, p. 3-2110. 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.
Read-do-call—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.
Challenge-confirm-do—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:
Cautions alert pilots to important preconditions, consequences of action steps, or consequences of the condition.
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, higher than, need longer runway.
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 manor. 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 it appears in brackets in the checklist. A majority of operators have reported that current information is inadequate and needs further “amplification”.
Technical data that are integral to checklist use are 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.
These are the design features of the QRH that provide landmarks to indicate where the pilot is in the checklist (such as page numbers and headings) 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 refers to the physical arrangement of the checklists within the document. Currently they are arranged alphabetically within system.
These features relate to characteristics of the physical document, such as size, shape, page color, page texture, binding, etc.
Draft 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 feature include tables of contents, light indices, categorization by system, etc.
1. Panel lights, EICAS message, and other triggers should have maximum discriminability to minimize the chance of going to the wrong checklist.
2. EICAS messages that do not have checklists should be coded in differently than those leading to checklists.
3. Eliminate “pilot awareness” checklists.
4. 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. For example:
5. The transition from triggering message to checklist should be direct with no additional cognitive analysis or interpretation required.
6. When the actions required by different checklists or checklist steps conflict (e.g., set flaps at 20 degrees vs. 15 degrees), the checklist or other procedures should provide information to help pilots resolve the conflict.
7. 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.
8. Checklists containing memory steps should be coded in the checklist selection tables and indices.
9. Pilots should have immediate access. to a list of conditions associated with checklists for unannunciated conditions.
Immediate action memory steps should be minimized to only those actions that must be initiated and completed within 5 seconds. Decision steps should not be memory steps.
Immediate action steps should be presented in a convenient location that can be read within a few seconds.
Guidance from the end of the presentation of immediate action steps to the full checklist should be provided with clear reference to the appropriate page number.
Immediate action steps should be repeated in the full checklist in a manner that visually sets them apart from non-memory steps.
Checklists are identified through a checklist title and other information, such as triggering information and aircraft condition giving rise to the triggers. Prototype concepts are provided following the guidelines.
Each procedure should have a distinctive title.
Page numbers should be prominently and saliently displayed near the checklist title. Any checklist with more than one page must begin on an even number.
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.
Contextual information should be visually grouped and set off from the procedure 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
Each step should be numbered.
Steps should be worded in simple, precise language.
Where possible, graphic elements should be included to rapidly convey important information.
Present steps without other information.
Decision, action (including memory steps), and navigation steps should be easily discriminated from each other.
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.
1. The specific items to consider in the decision step should be grouped together.
2. Whenever possible, decision steps should be completely closed.
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.
Where possible, declarative statements of conditions should be presented rather that using conditional operators.
Significant decision terms should be highlighted. Keep the use of these terms to a minimum whenever possible.
The outcome of the decision step(s) should be either navigation to the proper part of the checklist or to anther 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.
2. Clear initiation criteria should be provided (clear indication of when to start).
3. Clear termination criteria should be provided (clear indication of when to stop, even if checklist is not complete).
4. 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.
Important actions, like setting flaps, should be highlighted.
All keywords need to be salient.
Related steps should be visually grouped.
Navigation Steps
1. 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.
All steps are numbered and the navigation steps provide guidance that should help to positively guide pilots at every step.
In the second prototype, the decision step is distinguished by bold font and color is used to enhance navigation by creating visual momentum between the decisions and their applicable action steps. Shading differences can also be used to help establish the links and/or color for something else such as priority. If color is used for this purpose, pale rather than saturated colors should be used since they have low salience. However, with the background coloring, the eye can rapidly see the connection. The advantage of this approach is that it creates a relatively unobtrusive link between the decision and the appropriate action steps that is compelling and should minimize the possibility of going to the wrong steps.
Many of the Operator QRHs use arrows and lines to accomplish the same thing. The prototype below is a variation of this approach.
An alternative to the use of lines, using only symbols is presented below:
Cautions
Cautions alert pilots to important preconditions or consequences of action steps.
Cautions should be highly salient.
Cautions should be collocated with the appropriate step.
Where appropriate, information should be provided as to whether the caution applies prior or after the relevant step.
Prototype Concepts: Several approaches to coding of cautions using color (yellow) or a symbol (international alert symbol) are presented below. In the first prototype, yellow is used to signal a caution. A dot is placed after the step to indicate that the caution is applicable after the step has been taken. In the second two prototypes, a symbol is used to indicate the existence of a caution. Examples are shown for applicability of the caution before and after the step respectively. In selecting between color or symbology, one consideration is whether color will be used to indicate priority. If color is used for priority, e.g., red to indicate high-priority and yellow to indicate medium priority, then yellow should not be used for cautions. In that case symbols are preferred.
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 adds 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.
Visual aids should be used to assist pilots in assist locating supporting technical data.
The prototype below illustrates the guidance. Technical information in collocated with the guideline, but on the facing page. Visual aids draw the pilot's attention to the needed information. In this case the triangle at the end of the procedure step provides a cue to the existence of the supporting information and technical data.
The alternative prototype below uses a note to direct the pilot to the appropriate information below.
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.
Supporting information should be located near the appropriate action step but not in such as way as to divide the sequence of steps.
An indication should be provided for those steps for which supporting information is available.
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, 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 should 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 and headings) 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). Prototypes of many of these features were presented earlier.
Page numbers should be visible when the pilot is in the front of the QRH.
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.
Support should be provided for identifying currently active steps.
Visual aids and guidance should be 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 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 they are arranged alphabetically within system.
Checklists should be organized to minimize the need for navigation through the QRH.
Combining lots of things into one checklist should be avoided.
Where possible, checklists should address less than worse-case scenarios.
Separate NC checklists and NNC checklists into two documents.
These features relate to characteristics of the physical document, such as size, shape, page color, page texture, binding, etc.
Pages should be white.
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 a preferred embodiment and generally referring to
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
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 invention and are not intended to limit it.
This application claims the benefit of U.S. Provisional Application No. 60/502,135, filed on Sep. 11, 2003. The disclosure of the above application is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60502135 | Sep 2003 | US |
