Keywords

1 Introduction

All elements of the Flight Deck are influenced by human performance, especially the flight crews. In turn, human performance is influenced by many aspects of Flight Deck design, including the equipment that flight crews interface with, training they receive and procedures they use. These aspects of Flight Deck and system design are addressed by HFE [1].

In the past, human factors engineering analysis has been mostly accomplished on a case-by-case basis, in a somewhat understand manner. This has led to three main problems [2].

  • Inconsistencies in the design process itself.

  • Untimely application of human engineering principles.

  • Lack of systems integration.

A structured HFEP is an approach to solve the above problems. Experience has shown that when HFE activities are performed independently from other engineering activities, their impact and effectiveness is greatly decreased. In fact, addressing the human factors aspects of the Flight Deck is an activity that is best conducted early and continuously throughout the Civil Aircraft engineering design and development life cycle and not something that happens only at the end of a program during the formal certification test phase. As such, there may be some information generated as part of the engineering design process that could be used for certification as well.

2 Goals and Overviews of the HFEP

The primary goal of the Civil Aircraft Flight Deck HFEP is to provide a systematic method for integrating HFE into Flight Deck analysis, design, evaluation, and implementation to achieve safe, efficient, and reliable operation. Other goals include the following:

  • Providing design criteria to guide HFE implementation.

  • Integrating an HFEP that can be practically implemented.

  • Ensuring flight crews can perform tasks within the established safety, time, and performance criteria with the Human-Machine Interfaces (HMI) provided.

  • Providing acceptable workload levels for flight crews.

  • Providing a design that helps prevent human error and provides for error prevention, detection, and recovery capability.

  • Providing a high-quality interface between flight crews and Flight Deck systems that ensures safe operation, and alerts flight crews on either non-normal or emergency condition.

Figure 1 represents the overview of Civil Aircraft Flight Deck HFEP, which including a number of activities and the relative timing of HFE activities with respect to the design phases.

Fig. 1.
figure 1

An overview of the Civil Aircraft Flight Deck HFEP

However, Flight Deck integration is an iterative process. While the activities are presented below in serial fashion, they will be performed throughout the course of the Aircraft design and development program and will occur in parallel with each other. Thus, for example, there may be a preliminary allocation of function before any analysis work begins, e.g., as part of a preliminary specification of Flight Deck systems. However, the allocation will be analysed further as part of that HFE activity to better specify the basis for allocating functions. The function allocation may be revised across the design process as the design becomes more detailed and evaluations of systems performance are made.

3 Detail Description of the Activities in HFEP

3.1 HFE Program Planning

Purpose and Objectives.

The main purpose and objective of HFE program planning is to integrated HFE into the Flight Deck Design and Integration Process. To achieve the key goal and attribute of the HFE Progress identified in Sect. 2, HFE should be fully integrated into the overall Aircraft development and engineering process. This will help ensure timely and complete interaction with other engineering activities.

Inputs.

The inputs include but are not limited to:

  • Aircraft mission and operational requirements, including mission range and duration, airline company standard operating procedures, as well as landing capability and dispatch requirements. It is also important to define all of environments in which the aircraft is to operate.

  • Market strategy drivers, such as cost targets, training and proficiency goal, safety goal, maintainability strategies, functionality requirements and objectives.

  • Pilot operational experience and pilot capabilities.

  • Flight deck design philosophy.

  • Appropriate regulations.

  • Program Integrated Master Plan/Schedule.

Core Tasks.

This activity involves planning for the HFE aspects of the Flight Deck design and integration program. This includes identifying (1) the general HFE program goals and scope, (2) high-level concept of operations for the Flight Deck, (3) HFE design team skills necessary to conduct subsequent HFE activities (responsibilities of the main design team and contractors should be clearly stated), (4) engineering procedures (such as quality assurance and the use of an issues tracking system) to be followed, and (5) key milestones and scheduled to ensure the timely completion.

Outputs and Checklists for Completion.

The output of the HFE program planning activity should be documented in a human factors program plan that can be used to manage the overall HFE effort and could compliance with the following checklist. Does the HFE Program Plan identify:

  • general HFE program goals and scope?

  • high-level concept of operations for the Flight Deck?

  • HFE design team skills necessary to conduct subsequent HFE activities?

  • engineering procedures (such as QA and use of an issues tracking system) to be followed?

  • key milestones and scheduled to ensure the timely completion?

Are the results of the planning activity documented in a human factors program plan that can be used to manage the overall HFE effort?

Recommended Practices.

Engage appropriate multi-disciplinary team. The team should consist of pilots, Flight Deck design and integration, systems engineers, mechanical engineers, Engineering/Program Management specialists, and human factors engineers. An effective skill set includes:

  • Flight operations (line pilots are important in uncovering unintended uses of prior designs).

  • Human factors.

  • Systems engineering.

  • Certification.

  • Airspace operations, e.g., Air Traffic Management (ATM), Airport and/or Airline Operational Communications (AOC).

  • Program Management.

3.2 Existing Constraints Review

Purpose and Objectives.

Existing Constraints imposed on the Flight Deck integration mainly include the operational experience and capabilities of the flight crew [3] and the expected operating environment [2] of the Civil Aircraft. Existing Constraints Review (ECR) is used to identify all the potential conflicts and issues between the Flight Deck design proposal and all the constraints mentioned above.

Inputs.

The inputs include but are not limited to:

  • Flight crew operational experience and capabilities, including general human anthropometry, perceptual and cognitive abilities.

  • Human reliability data.

  • Expected operation environment. This may include routing (e.g., polar, oceanic, non-ICAO), aircraft limitations (e.g., cruise altitude, range, speed), atmospheric conditions, runway types and conditions, desert and/or arctic operations, and type of maintenance support, etc.

Core Tasks.

ECR is performed to understand (1) current or planned work practices so the potential impact of planned changes, such as the introduction of new systems and new responsibilities and tasks or the introduction of new performance schedules, can be assessed, (2) operational problems and issues may be addressed in a new design or modification of an existing design, and (3) relevant domain experience with candidate system technology approaches.

Outputs and Checklists for Completion.

The outputs of this activity is an identification of the flight crew capabilities and operating environment in which the aircraft and Flight Deck systems will have to perform and definition of the unique requirements of Flight Deck system which will provide for safe and efficient operation within that environments. And the completion checklist should be:

  • Are ECR documents maintained and readily accessible to the design team?

  • Do they provide a clear indication of issues identified, the design activities to which they are relevant, and their importance?

Recommended Practices.

ECRs should be held periodically during the project/program cycle, as designs change, operations change, or other developments occur. OERs should be implemented as a series, first as a stand-alone, and then subsequent one as an element of the existing design review cycle.

3.3 Function Analysis and Allocation

Purpose and Objectives.

The overall purpose of function analysis and allocation is to ensure that functional requirements are sufficiently defined and analyzed so that the allocation of functions to the available resources can take advantage of the strengths of each. In other words, make use of automation and human capabilities in ways that maximize overall function accomplishment.

Inputs.

The inputs include but are not limited to:

  • A clear definition of the intended function of the Flight Deck/system including how the flight crew will use it.

  • Flight Deck philosophy, especially the automation design principles.

  • Aircraft operational concept.

Core Tasks.

The core tasks may include:

  • Conduct Function Analysis and trade-off. Use a “top-down” approach, which starting at the “top” of the hierarchy with the system’s high-level mission and goals, to divided the aircraft level functions into the sub-functions until which could be accomplished by a single system or flight crew.

  • Define Scenarios for evaluation.

  • Conduct Function Allocation Evaluation. This analysis is performed for each scenario. As the whole function analysis and allocation process is iterative, this analysis can begin at the earliest design stages. Allocations can be refined or adjusted as more information about performance is known and evaluations are conducted.

  • Evaluate Allocations across Scenarios.

  • Evaluate Overall Personnel Role.

  • Verify Allocations.

Outputs and Checklists for Completion.

The specification of which functions should be carried out by the users and which by the technology. And the completion checklist should be:

  • Have the various functions needed to achieve the mission been described?

  • Has the allocation of responsibility for conducting functions, or parts of functions, to personnel, to automatic systems, or to some combination of the two been made?

  • Is the allocation made on the basis of a function analysis to determine what is required to perform the function?

  • Have the roles and responsibilities of personnel and automation in the performance of system functions, including how they may be changed as a result of various types of failure conditions?

Recommended Practices.

These design decisions determine the extent to which a given job, task, function or responsibility is to be automated or assigned to human performance. The decisions should be based on many factors, such as relative capabilities and limitations of humans versus technology in terms of reliability, speed, accuracy, strength, flexibility of response, financial cost, the importance of successful or timely accomplishment of tasks and user well-being. They should not simply be based on determining which functions the technology is capable of performing and then simply allocating the remaining functions to users, relying on their flexibility to make the system work. The resulting human functions should form a meaningful set of tasks. Representative users should generally be involved in these decisions. Function allocation analysis is a continuous and ongoing process. While initially qualitative evaluations as discussed here are necessary, allocation acceptability is continuously evaluated as part of later design activities. When mockups, simulators, and other tools become available, function allocations can be evaluated by measuring actual performance.

3.4 Task Analysis

Purpose and Objectives.

Each sub-function can be broken down into tasks. The objective of task analysis is to specify the requirements for successful task performance, e.g., what alarms, information, controls, communications, and procedures are needed for flight crew to accomplish their assigned functions.

Inputs.

The inputs include but are not limited to:

  • Function definition and documented, organized, and consistent set of requirements.

  • Baseline flight deck definition and operational procedures.

  • Flight deck design philosophy.

Core Tasks.

The core tasks may include:

  • Identify Tasks need to be analysed. It may not be necessary to perform task analysis on all tasks. For example, if a system function is well known and essentially unchanged from predecessor systems, it may not be necessary to reanalyse it.

  • Develop High-Level Task Descriptions. Including purpose, task initiation, preconditions, time constraints, task termination and task failure criteria.

  • Develop Detailed Task Descriptions. Including low-level description, completeness of the task decomposition, consequence tasks, evaluation results of time-critical tasks, and additional considerations as needed.

  • Assign Tasks to Flight Crew. Tasks need to be assigned to individual Flight Crew according to each flight phase.

  • Identify Task Requirements. Including information requirements, decision-making requirements, response requirements, communication requirements, workload, task support requirements and workplace factors. These requirements are a major input to HMI and procedure design, as well as training.

Outputs and Checklists for Completion.

The outputs of this activity are a set of tasks performance requirements. And the completion checklist should be:

  • Do the task analyses specify the requirements for successful task performance, e.g., what alarms, information, controls, communications, and procedures are needed?

Recommended Practices.

Two parameters to consider in allocating tasks between crew members and aircraft systems are keeping both the pilot workload and “pilot in the loop” activities at the appropriate level.

3.5 Human Error Analysis

Purpose and Objectives.

This activity is performed to evaluate the potential for, and mechanisms of, human error in Flight Crew operations and identify the appropriate methods to decrease the probability or to mitigate the hazard.

Inputs.

The inputs include but are not limited to:

  • Relevant Operational Experience Reviews.

  • Incident and accident databases.

  • Flight Crew tasks definition.

  • Flight Deck System behaviour.

Core Tasks.

The core tasks may include:

  • Identify critical Flight Crew tasks to analyse. Especially for the complex and/or novelty systems. As well as conventional systems operations during high workload flight phase.

  • Criticality Safety analysis. Analyse the hazards due to the flight crew error to define the associated level of protections.

Outputs and Checklists for Completion.

Have significant Flight Crew tasks (i.e., those that impact mission success, the safety of system operations, and where Flight Crew safety is an issue) been identified and analyzed in detail? Have these been evaluated with sufficient detail so that error tolerant design strategies (minimize Flight Crew errors, allow their detection, and provide recovery capability) can be applied to manage them, e.g., through the design of Human-System Interfaces, procedures, training, and automation?

Recommended Practices.

Fault Tree Analysis and Human Factors Process Failure Mode and Effects Analysis (HFPFMEA) are the two practical analysis techniques [4].

3.6 Human-Machine Interface and Procedure Design

Purpose and Objectives.

This activity is performed to develop the Flight Deck detail HMI proposal and Flight Crew procedure.

Inputs.

The inputs include but are not limited to:

  • Flight Deck design philosophy.

  • Aircraft mission and operational requirements.

  • List of HMI issues associated with requirements.

  • Technology capabilities.

Core Tasks.

The core tasks may include:

  • HMI requirements capture. The analyses discussed in previous sections result in requirements for the HMI and procedures.

  • Flight crew concept of operation. Alternative operation concept of meeting the requirements should be identified or developed previously and comes down to the final concept via trade-off evaluations, usability evaluations and performance-based tests and evaluations.

  • Develop Display Formats and Controls Scheme.

  • HMI detail design and implementation.

Outputs and Checklists for Completion.

At the end of this step (when it is decided to do formal testing for certification), documents required to be completed may be revised to include the final HMI and procedure design specifications. And the completion checklist should be:

  • Does the HMI provide the resources needed by Flight Crew to interact with the systems?

  • Do HMIs and procedures that (1) reflect the system’s functional and physical design, (2) meet flight crew task requirements, (3) exhibit the general characteristics of well-designed HMI and procedures, and (4) are easy to learn and use?

Recommended Practices

  • Engage a multi-disciplinary team for both design and regulatory agency teams.

  • Quick iteration of solutions and evaluations.

  • Provide the higher-level documents such as the Flight Deck Design Philosophy and Flight Crew Operational Requirements, and rationale/assumption document to all team members.

  • Where system is complete enough, involve currently flying line pilots in evaluations.

3.7 HFE Verification and Validation

Purpose and Objectives.

The goal of this step is to show compliance to the applicable human factors related regulations and to achieve final certification authority approval of compliance to the human factors related regulations, based on the deliverables presented.

Inputs.

The inputs include but are not limited to:

  • Certification Plan for human factors compliance.

  • Test plan and test procedures including human factors considerations.

Core Tasks.

The core tasks may include:

  • Formal Testing. Formal testing is done on an article or component that conforms to the proposed type design in form, fit, and function.

  • Tasks and activities for the applicant include the submission of all agreed-upon human factors data.

  • Tasks and activities for the certification authority include reviewing all human factors data and determining if all human factors related regulations have been complied with.

Outputs and Checklists for Completion.

The results of human factors test and analyses will be included in a formal test or compliance report. The certification authority communicates to the applicant the outcomes of the certification authority review: approval or disapproval.

Recommended Practices.

Develop a common understanding between the certification authority and the applicant about the relevant human factors aspects and potential issues related to the applicant’s product. Establish an ongoing dialog with the certification authority during the design evolution through regularly scheduled familiarization meetings at each stage of development, including early prototype development and evaluation.

3.8 Test and Evaluation

This activity is an integral part of the entire HFEP and spans the full Civil Aircraft Flight Deck design life cycle. Overall objectives are to validate HFE requirements, Various engineering evaluation techniques include:

  • Interviews of users.

  • Procedure evaluations (e.g., complexity, number of steps).

  • Walk-throughs using drawings.

  • Reach analysis via computer modelling.

  • Time-line analysis for assessing task demands and workload.

  • Operational sequence diagrams.

  • Usability or heuristic evaluations.

  • Walk-throughs using drawings, mock-ups, or prototypes.

  • Performance-based tests, such as can be conducted on a full-mission simulator.

4 Summary and Conclusions

The Civil Aircraft Flight Deck system design include controls, displays, crew alerts, checklists, and procedures. HFE issues relate to all aspects of the Flight Crews, across the spectrum of expected operating conditions (nominal, non-normal, and emergency). This paper introduced a HFEP to identify and manage the HFE issue under a structive way, which has been proven to be more practical.

However, this process is not mandatory and users of this information can either utilize the process and or develop another procedure tailored to their particular development and/or environment.