AMC1 SPA.EFB.100(b)(2) Use of electronic flight bags (EFBs) – Operational approval    

CAA ORS9 Decision No. 1

HUMAN–MACHINE INTERFACE ASSESSMENT AND HUMAN FACTORS CONSIDERATIONS

(a) The operator should perform an assessment of the human–machine interface (HMI), the installation, and aspects governing crew resource management (CRM) when using the EFB system.

The HMI assessment is key to identifying acceptable mitigation means, e.g.:

(1) to establish procedures for reducing the risk of making errors; and

(2) to control and mitigate the additional workload related to EFB use.

(b) The assessment should be performed by the operator for each kind of device and application installed on the EFB. The operator should assess the integration of the EFB into the flight deck environment, considering both physical integration (e.g. anthropometrics, physical interference, etc.) and cognitive ergonomics (the compatibility of look and feel, workflows, alerting philosophy, etc.).

(1) Human–machine interface

The EFB system should provide a consistent and intuitive user interface within and across the various hosted applications and with flight deck avionics applications. This should include but is not limited to data entry methods, colour-coding philosophies, and symbology.

(2) Input devices

When choosing and designing input devices such as keyboards or cursor-control devices, applicants should consider the type of entry to be made and also flight crew compartment environmental factors, such as turbulence, that could affect the usability of that input device. Typically, the performance parameters of cursor-control devices should be tailored for the function of the intended application as well as for the flight crew compartment environment.

(3) Consistency

(i) Consistency between EFBs and applications:

Particular attention should be paid to the consistency of all interfaces, in particular when one provider develops the software application and another organisation integrates it into the EFB.

(ii) Consistency with flight deck applications:

Whenever possible, EFB user interfaces should be consistent with the other flight deck avionics applications with regard to design philosophy, look and feel, interaction logic, and workflows.

(4) Messages and the use of colours

For any EFB system, EFB messages and reminders should be readily and easily detectable and intelligible by the flight crew under all foreseeable operating conditions.

The use of red and amber colours should be limited and carefully considered. EFB messages, both visual and aural, should be, as far as practicable, inhibited during critical phases of the flight.

Flashing text or symbols should be avoided in any EFB application. Messages should be prioritised according to their significance for the flight crew and the message prioritisation scheme should be documented in the operator’s EFB policy and procedure manual.

Additionally, during critical phases of the flight, information necessary to the pilot should be continuously presented without uncommanded overlays, pop-ups, or pre-emptive messages, except for those indicating the failure or degradation of the current EFB application. However, if there is a regulatory or technical standard order (TSO) requirement that is in conflict with the recommendation above, that requirement should take precedence.

(5) System error messages

If an application is fully or partially disabled or is not visible or accessible to the user, it may be desirable to have an indication of its status available to the user upon request. Certain non-essential applications such as those for email connectivity and administrative reports may require an error message when the user actually attempts to access the function, rather than an immediate status annunciation when a failure occurs. EFB status and fault messages should be documented in the operator’s EFB policy and procedure manual.

(6) Data entry screening and error messages

If any user-entered data is not of the correct format or type needed by the application, the EFB should not accept the data. An error message should be provided that communicates which entry is suspect and specifies what type of data is expected. The EFB system should incorporate input error checking that detects input errors at the earliest possible point during entry, rather than on completion of a possibly lengthy invalid entry.

(7) Error and failure modes

(i) Flight crew errors:

The system should be designed to minimise the occurrence and effects of flight crew errors and to maximise the identification and resolution of errors. For example, terms for specific types of data or the format in which latitude/longitude is entered should be the same across systems.

(ii) Identifying failure modes:

The EFB system should alert the flight crew of EFB system failures.

(8) Responsiveness of applications

The EFB system should provide feedback to the user when a user input is performed. If the system is busy with internal tasks that preclude the immediate processing of a user input (e.g. performing calculations, self-tests, or refreshing data), the EFB should display a ‘system busy’ indicator (e.g. a clock icon) to inform the user that the system is occupied and cannot process inputs immediately.

The timeliness of the EFB system response to a user input should be consistent with an application’s intended function. The feedback and system response times should be predictable in order to avoid flight crew distractions and/or uncertainty.

(9) Off-screen text and content

If the document segment is not visible in its entirety in the available display area, such as during ‘zoom’ or ‘pan’ operations, the existence of off-screen content should be clearly indicated in a consistent way. For some intended functions, it may be unacceptable if certain portions of documents are not visible. Also, some applications may not require an off-screen content indicator when the presence of off screen content is readily obvious. This should be evaluated based on the application and its intended operational function. If there is a cursor, it should be visible on the screen at all times while in use.

(10) Active regions

Active regions are regions to which special user commands apply. The active region can be text, a graphic image, a window, frame, or some other document object. These regions should be clearly indicated.

(11) Managing multiple open applications and documents

If the electronic document application supports multiple open documents, or the system allows multiple open applications, an indication of which application and/or document is active should be continuously provided. The active document is the one that is currently displayed and responds to user actions. The user should be able to select which of the open applications or documents is currently active. In addition, the user should be able to find which flight crew compartment applications are running and easily switch to any of these applications. When the user returns to an application that was running in the background, it should appear in the same state as when the user left that application, with the exception of differences stemming from the progress or completion of processing performed in the background.

(12) Flight crew workload

The positioning of the EFB and the procedures associated with its use should not result in undue flight crew workload. Complex, multi-step-data-entry tasks should be avoided during take-off, landing, and other critical phases of the flight. An evaluation of the EFB intended functions should include a qualitative assessment of the incremental flight crew workload, as well as the flight crew system interfaces and their safety implications.