Advisory Circular (AC) No. 700-020

Subject: Electronic Flight Bags

Issuing Office:	Civil Aviation, Standards
Document No.:	AC 700-020
File Classification No.:	Z 5000-34
Issue No.:	03
RDIMS No.:	10784721-V24
Effective Date:	2018-03-28

Table Of Contents

• 1.0 Introduction
  • 1.1 Purpose
  • 1.2 Applicability
  • 1.3 Description of Changes
• 2.0 References and Requirements
  • 2.1 Reference Documents
  • 2.2 Cancelled Documents
  • 2.3 Definitions and Abbreviations
• 3.0 Background
• 4.0 Implementation Process
• 5.0 Classification of Electronic Flight Bags Systems
  • 5.1 Hardware Classes of Electronic Flight Bags
• 6.0 Electronic Flight Bags Installations and Related Evaluation Requirements
  • 6.1 Portable EFB Electronic Flight Bags Hardware
  • 6.2 Installed Electronic Flight Bags Hardware
• 7.0 Air Operator Electronic Flight Bags Operational Implementation Procedures
• 8.0 Information Management
• 9.0 Document History
• 10.0 Contact Office
• Appendix A — Examples of “Type A” Electronic Flight Bags Applications
• Appendix B — Examples of “Type B” Electronic Flight Bags Applications
• Appendix C — Electronic Flight Bags Classification Matrix
• Appendix D — Electronic Flight Bags Evaluation Process
• Appendix E — Electronic Flight Bags Evaluation Checklist
• Appendix F — Electronic Flight Bag Software Applications Evaluation Checklists
• Appendix H — Operational Evaluation Checklist—Corporate/Company Level
• Appendix I — Operational Aircraft Evaluation
• Appendix J — Operational Evaluation Checklist—Aircraft
• Appendix K — Supplemental Guidance for the Development of EFB Software Applications

1.0 Introduction

• (1) This Advisory Circular (AC) is provided for information and guidance purposes. It describes an example of an acceptable means, but not the only means, of demonstrating compliance with regulations and standards. This AC on its own does not change, create, amend or permit deviations from regulatory requirements, nor does it establish minimum standards.

1.1 Purpose

• (1) The purpose of this document is to:
  • (a) provide guidelines for the certification, airworthiness and operational approval of Portable Electronic Devices (PEDs), portable and installed, used as Electronic Flight Bags (EFBs);
  • (b) specify the principle that all EFBs to be used on an aircraft are to be subjected to a defined evaluation process;
  • (c) minimize the burden on operators, installers, manufacturers, and Transport Canada Civil Aviation (TCCA) by specifying that some EFB evaluations can be delegated;
  • (d) provide specific guidance material for certain EFB applications and approvals and establish certification, airworthiness/installation, and operational approval guidance for EFB systems; and
  • (e) provide checklists to assist operators, installers and TCCA in evaluating proposed EFB implementations.

1.2 Applicability

• (1) This document applies to TCCA personnel, delegates, and the aviation industry.

1.3 Description of Changes

• (1) This document, defines an EFB system as either portable or installed and replaces previous issues which had three classifications of EFBs (Class1, Class 2 or Class 3) to harmonize with the International Civil Aviation Organization (ICAO), and to accommodate increasingly complex systems integrating both installed and portable equipment.
• (2) Reorganizes Type A and B applications to align them to the safety criticality of the function they are performing.
• (3) Eliminate Type C applications since they are non-EFB applications.
• (4) Guidance is provided for EFB own-ship position in conjunction with EFB applications, such as electronic charts.

2.0 References and Requirements

2.1 Reference Documents

• (1) It is intended that the following reference materials be used in conjunction with this document:
  • (a) Part I, Subpart 3 of the Canadian Aviation Regulations (CARs) — General Provisions;
  • (b) Subpart 602 of the CARs — Operating and Flight Rules;
  • (c) Subpart 604 of the CARs — Private Operator Air Transportation;
  • (d) Subpart 702 of the CARs — Aerial Work;
  • (e) Subpart 703 of the CARs — Air Taxi Operations;
  • (f) Subpart 704 of the CARs — Commuter Operations;
  • (g) Subpart 705 of the CARs — Airline Operations;
  • (h) Chapter 523 of the Airworthiness Manual (AWM) — Normal, Utility, Aerobatic and Commuter Category Aeroplanes;
  • (i) Chapter 525 of the AWM — Transport Category Aeroplanes;
  • (j) Chapter 527 of the AWM — Normal Category Rotorcraft;
  • (k) Chapter 529 of the AWM — Transport Category Rotorcraft;
  • (l) Advisory Circular (AC) 700-005, Issue 03, 2014-04-15 — Use of Transmitting and Non-Transmitting Portable Electronic Devices;
  • (m) Commercial and Business Aviation Advisory Circular (CBAAC) 0260, Original issue, 2007-03-20 — Potential for In-Flight Fires Due to Lithium Battery Failure;
  • (n) Service Difficulty Alert (AL)-2009-06, Original Issue, 2009-08-13 — Procedures For Fighting Fires Caused by Lithium Type Batteries in Portable Electronic Devices;
  • (o) Civil Aviation Safety Alerts (CASA) 2016-02, Issue 01, 2016-02-12 — The Possibility of Smoke or Fire From Electronic Flight Bags (EFBs) or Their Lithium Ion Batteries;
  • (p) European Aviation Safety Agency (EASA) Acceptable Means of Compliance (AMC) 20-25 Annex II — Airworthiness and operational consideration for Electronic Flight Bags (EFBs);
  • (q) Federal Aviation Administration (FAA) Title 14, Code of Federal Regulations (CFR), Part 21 — Certification Procedures for Products and Parts;
  • (r) FAA AC 20-173(), 2011-09-27 - Installation of Electronic Flight Bag Components;
  • (s) FAA AC 120-64(), 1996-04-24 — Operational Use & Modification of Electronic Checklists;
  • (t) FAA AC 120-76(), 2017-10-27 — Authorization for Use of Electronic Flight Bags;
  • (u) FAA Order 8900.1 — Flight Standards Information Management System (FSIMS), Vol 4, Chap 15;
  • (v) FAA Safety Alert for Operators 09013 — Fighting Fires Caused By Lithium Type Batteries in Portable Electronic Devices;
  • (w) FAA Safety Alert for Operators 15010 - Carriage of Spare Lithium Batteries in Carry-on and checked baggage;
  • (x) International Civil Aviation Organization (ICAO) Document 9481 — Emergency Response Guidance for Aircraft Incidents Involving Dangerous Goods (Lithium Battery Fire Checklist);
  • (y) ICAO Document 9481 AN/928 — CORRIGENDUM 1 - Emergency Response Guidance for Aircraft Incidents Involving Dangerous Goods (Lithium Battery Fire Checklist);
  • (z) ICAO Document 10020 — Manual on Electronic Flight Bags (EFBs), Second Edition – 2017;
  • (aa) Radio Technical Commission for Aeronautics (RTCA) /DO-160(), Environmental Conditions and Test Procedures for Airborne Equipment.
  • (bb) RTCA/DO–178() — Software Considerations in Airborne Systems and Equipment Certification;
  • (cc) RTCA/DO-201() — User Requirements for Aeronautical (Navigation) Information;
  • (dd) RTCA/DO-257() — Minimum Operational Performance Standards for the Depiction of Navigational Information on Electronic Maps;
  • (ee) RTCA/DO-272() — User Requirements for Aerodrome Mapping Information;
  • (ff) RTCA/DO-294() — Guidance on Allowing Transmitting Portable Electronic Devices (T-PEDS) on Aircraft;
  • (gg) RTCA/DO311() — Minimum Operational Performance Standards for Rechargeable Lithium Batteries, and
  • (hh) RTCA/DO-363() – Guidance for the Development of Portable Electronic Devices (PED) Tolerance for Civil Aircraft.

2.2 Cancelled Documents

• (1) As of the effective date of this document, the following documents are cancelled:
  • (a) Transport Canada (TC) Internal Process Bulletins (IPB) 2014-06, Issue 1, dated 2014-10-24 — The Operational Use of Class 1 Electronic Flight Bags (EFBs) Using Suction Cup Mounts in All Phases of Flight.
• (2) By default, it is understood that the publication of a new issue of a document automatically renders any earlier issues of the same document null and void.

2.3 Definitions and Abbreviations

• (1) The following definitions are used in this document:
  • (a) Aircraft Flight Manual (AFM): For the purposes of this AC the term AFM applies equally to aeroplanes, rotorcraft, and airships.
  • (b) Aircraft Administrative Communications (AAC): Data link that can receive/transmit information that includes but is not limited to, the support of applications identified in Appendices A and B of this AC.
  • (c) Electronic Flight Bag (EFB): An electronic display system intended primarily for cockpit or cabin use. EFB devices can display a variety of aviation data or perform calculations such as performance data and fuel calculations. In the past, some of these functions were traditionally accomplished using paper references or were based on data provided to the flight crew by an airline’s “flight dispatch” function. The scope of the EFB system functionality may also include various other hosted databases and applications. Physical EFB displays may use various technologies, formats, and forms of communication. These devices are sometimes referred to as auxiliary performance computers (APC) or laptop auxiliary performance computers (LAPC).
  • (d) EFB Administrator: The EFB Administrator is the person appointed by the Air Operator for the administration of the EFB system within its company. The EFB Administrator will be the person in overall charge of the EFB system and will be responsible for ensuring that the hardware conforms to the required specification, and that only Company authorized software is installed. They will also be responsible for ensuring that only the current version of any application and data packages are installed on the EFB system.
  • (e) EFB Software Application: Software installed on an EFB system that allows specific operational functionality.
  • (f) EFB System: An EFB system includes the hardware and software needed to support an intended function.
  • (g) Interactive Information: Information presented on the EFB that, via software applications, can be selected and rendered in a number of dynamic ways. This includes variables in the information presented based on data-oriented software algorithms, concepts of de-cluttering, and “on-the-fly” composition as opposed to pre-composed information.
  • (h) Installed Equipment: A component that is incorporated into the aircraft type design and, as such, is subject to airworthiness authority approval.
  • (i) Mounting Device: A device that can be used to secure portable equipment. It may include arm-mounted, kneeboard, cradle, or docking stations, suction cups, etc. It may have aircraft power and data connectivity. It may require quick-disconnect for egress.
  • (j) Operating System: Software that controls the execution of programs and that may provide services such as resource allocation, scheduling, input-output control, and data management.
  • (k) Own-ship Position: Graphical depiction of aircraft position relative to other items depicted within an electronic map display.
  • (l) Principal Maintenance Inspector (PMI): A TCCA employee having principal responsibilities associated with a particular Air Operator for maintenance related issues.
  • (m) Principal Operating Inspector (POI): A TCCA employee having principal responsibilities associated with a particular Air Operator for operational issues.
  • (n) Portable Electronic Device (PED): A self-contained electronic device that is not permanently connected to any aircraft system, although it may be connected temporarily to an aircraft’s electrical power system, externally mounted antenna, data bus, or mounting device. PED’s include numerous communications and computing devices as detailed in AC 700-005—Use of Transmitting and Non-Transmitting Portable Electronic Devices. As defined in this AC, portable EFBs are considered PEDs.
  • (o) Controlled Portable Electronic Device (CPED): A CPED is a PED that is subject to administrative control by the operator using it. This includes tracking the location of devices to specific airframes or persons and ensuring that no unauthorized changes are made to the hardware, software or databases. A CPED will also be subject to procedures to ensure that it is maintained to the latest amendment state.
  • (p) Pre-Composed Information: Information previously composed into a static composed state (non-interactive). The composed displays have consistent, defined and verifiable content, and formats that are fixed in composition.
  • (q) Type A EFB Software Application: – Software installed on an EFB providing a specific operational functionality, whose malfunction or misuse would have no adverse effect on the safety of any flight operation, that is a failure condition classification considered to be “no safety effect”. (Refer to Appendix A of this AC).
  • (r) Type B EFB Software Application: Software installed on an EFB providing a specific operational functionality, whose malfunction or misuse would have a “minor” failure condition classification. (Refer to Appendix B of this AC).
  • (s) Viewable stowage: A portable EFB (not mounted in a mounting device) may be used during all phase of flight provided that is secured on the flight crew (e.g. kneeboard) or in/to an existing aircraft part (e.g. suction cups) with the intended function to hold an acceptable portable device. This viewable stowage device is not part of the certified aircraft configuration.

3.0 Background

• (1) EFBs perform a variety of functions traditionally accomplished using paper references by electronically storing and retrieving documents required for flight operations, such as the Aircraft Flight Manual (AFM), the Flight Crew Operations Manual (FCOM) and Minimum Equipment Lists (MEL). EFBs are developed to support functions during all phases of flight operations. EFBs may be authorised for use in conjunction with or to replace some of the hard copy material that pilots and other crew members typically carry in their flight bags. The operator remains responsible for ensuring the accuracy of the information used and that it is derived from verifiable sources.
• (2) A mounting device permanently attached to the aircraft structure requires aircraft certification approval (e.g. an STC). However a suction cup mounted device is not permanently attached to the aircraft structure and therefore does not require aircraft certification approval; EFBs so mounted are considered as portable:
  • (a) While some operators may be able to adequately mitigate the risks of suction cup mounts for their operation, other operators may choose to get their EFB mounts certified as installed equipment, in accordance with the applicable aircraft certification requirements.
  • (b) For a certified mount installations for portable EFBs, the security of the mount, the cockpit visibility, the function of the mount, and egress considerations would be addressed as part of the certification process

4.0 Implementation Process

• (1) Paragraph This AC describes how the implementation of an EFB into an air operator’s operations will affect the following:
  • (a) EFB installation;
  • (b) EFB certification, where applicable; and
  • (c) Operational approval.
• (2) Section 6.0 of this AC discusses these aspects and describes two evaluation processes: one is directed at the evaluation of the EFB installation, and the other is directed at the operational evaluation. The operational evaluation is further divided into an evaluation of company procedures and processes and an aircraft evaluation.
• (3) Depending on the circumstances the EFB installation and operational evaluations may be carried out separately or as a combined exercise.
• (4) The evaluation of the installation aspects of the EFB covers both certified and non-certified aspects. It is expected that most evaluations will be conducted by non-TCCA personnel, and where this is the case, the only determination that the evaluator has to make with regard to the certified aspects of the EFB is that they have been approved by TCCA. In other words the non-TCCA evaluator is not expected to re-evaluate aspects of the EFB that have already been approved by TCCA.
• (5) Checklists are provided in the Appendices of this AC to assist with the evaluation of the installation and operational aspects of EFBs. Those aspects which are expected to be evaluated as part of the Transport Canada certification process are annotated “Certification”.

5.0 Classification of Electronic Flight Bags Systems

• (1) The hardware and software classes of EFB systems in this AC maintain commonality with EFB classification system as established by the International Civil Aviation Organization (ICAO), the FAA, and European Aviation Safety Agency (EASA) classification systems, respectively. Below is a description of the hardware and software classifications.

5.1 Hardware Classes of Electronic Flight Bags

• (1) EFBs can be either portable or installed.
  • (a) Portable EFBs are not part of the aircraft configuration, are not subject to normal airworthiness requirements and design control, and are considered as PEDs. They generally have self-contained power, and may rely on data connectivity to achieve full functionality. Modifications to the aircraft to use portable EFBs require the appropriate airworthiness approval.
  • (b) Installed EFBs are integrated into the aircraft, subject to normal airworthiness requirements and under design control. The approval of these EFBs is included in the aircraft’s type certificate or in a supplemental type certificate.

6.0 Electronic Flight Bags Installations and Related Evaluation Requirements

6.1 Portable EFB Electronic Flight Bags Hardware

• (1) Portable EFBs may:
  • (a) be used on the ground and during flight;
  • (b) connect to the aircraft’s power through a certified power source;
  • (c) have their batteries recharged onboard the aircraft;
  • (d) require quick-disconnect from power and/or data sources to allow for crew egress;
  • (e) have read-only data connectivity to other aircraft systems; and
  • (f) have receive/transmit data connectivity for Aircraft Administrative Communications (AAC) only.
• (2) This AC specifies an evaluation of Portable EFB s as detailed in Appendix D and the checklist provided in Appendix E. An organisation or individual may carry out this evaluation. The evaluation is to confirm that the EFB with installed software:
  • (a) meets basic human factors and functionality criteria;
  • (b) can be properly stowed for take-off and landing, or the proposed viewable storage means are acceptable;
  • (c) does not interfere with other aircraft systems or equipment; and
  • (d) is suitable equipment for use onboard an aircraft.
• (3) EFB data connections require TCCA Aircraft Certification approval to ensure non-interference and isolation from aircraft systems during transmission and reception. The EFB data connection may receive information from any aircraft system as well as receive or transmit information for AAC purposes. Connectivity may be wired or wireless.
  • (a) portable EFBs do not require compliance with RTCA/DO-160D, Environmental Conditions and Test Procedures for Airborne Equipment;
  • (b) mounting devices, power and data connectivity provisions for portable EFBs that are installed by supplemental type certificates (STC) may require an Aircraft Flight Manual Supplement (AFMS) update.
• (4) The operator shall ensure that the EFB batteries are compliant to the applicable standards for use and transportation in an aircraft including FAA Safety Alert for Operators (SAFO) 15010 - Carriage of Spare Lithium Batteries in Carry-on and checked baggage and ensure that operating procedures and crew member training are up to date regarding the use and cautions of lithium batteries and should include, as a minimum:
  • (a) Risk of leakage of corrosive electrolyte;
  • (b) Risk of venting of toxic or flammable gases;
  • (c) Risk of Smoke and/or Fire;
  • (d) Risk of Explosion;
  • (e) Safe storage of spare batteries including the potential for damage leading to short circuit; and
  • (f) Hazards due to overcharging and discharging of the device, including battery over-heat which may lead to thermal runaway and subsequent battery fire.
• (5) Operators shall review their emergency procedures and training and ensure the following items, as a minimum are addressed:
  • (a) lithium battery firefighting procedures;
  • (b) post-event procedures (on-board); and
  • (c) first point of landing offloading procedures.

6.2 Installed Electronic Flight Bags Hardware

• (1) Installed EFB hardware is installed equipment and requires TCCA Aircraft Certification design approval for all hardware, mounting and connectivity aspects. When certification processes for EFBs first appeared all software aspects of an installed EFB were to be approved together with the hardware aspects.
• (2) However installed EFBs have been subsequently designed to incorporate software partitioning in accordance with RTCA DO-178C so that non-approved software, could be installed. This concept then evolved one more step to installed EFBs which contained no certified software at all. For uncertified software running on an installed EFB, the following provisions apply:
  • (a) It must be demonstrated that there is no interaction between the certified and uncertified partitions of the EFB for Type A and B applications. Furthermore, the following statement must be added to the AFM or AFMS:
    • (i) “The EFB is partitioned into certified and uncertified partitions. The suitability, integrity and accuracy of the applications in the uncertified part of the EFB have not been assessed, and the capability of these applications to perform their intended function has not been verified or certified. Approval of the installation of the EFB in the aircraft does not constitute operational approval for any use of the EFB."
  • (b) Software components that are not incorporated into the aircraft type design may not transmit data to any aircraft system except that data may be transmitted to cabin service systems not associated with flight safety.
  • (c) Software components that are not incorporated into the aircraft type design may not be used to display own ship position information either on the ground or in the air.
  • (d) The non-approved software should also be subjected to the evaluation process described in Appendices D and G of this AC.

7.0 Air Operator Electronic Flight Bags Operational Implementation Procedures

General

• (1) Operators incorporating EFBs into their operations should carefully review the contents of this AC to determine applicable requirements. For the most part the level of complexity associated with the operational implementation will depend on the class of hardware and type of software used and the intended application (e.g. replace all paper approach charts with electronic charts).
• (2) Table 1 — EFB Classification Matrix in Appendix C of this AC summarizes the involvement of the various entities during the operational implementation of EFBs.
• (3) Regardless of hardware class or software type, the operational implementation will require a structured sequence of events and actions to satisfy both the operator and the regulator that aircraft equipped with an EFB(s) can be operated safely.
• (4) All software applications and information contained in the EFB intended for operational use must be current and up-to-date.
• (5) From a process perspective it is envisaged that the operator will:
  • (a) decide on the class and type of EFBs to use, based on a number of factors including the use of this AC;
  • (b) discuss any implementation concerns with their respective Principal Operations Inspector (POI) or Principal Maintenance Inspector (PMI);
  • (c) contact the appropriate Aircraft Certification authority, if the implementation requires changes or modifications to the aircraft;
  • (d) complete all necessary assessment, evaluations, document updates, training, etc.;
  • (e) submit changes to Company Operations Manual (COM) to POI for approval/acceptance; and
  • (f) submit changes to the maintenance schedule to the PMI for approval/acceptance as required.
• (6) Operational evaluations are required as detailed in Appendices G, H, I, and J of this AC.
  • (a) The first evaluation detailed in Appendix G of this AC is to ensure that the operator has properly addressed company implementation of EFBs. An evaluation checklist is provided in Appendix H of this AC.
  • (b) The second evaluation detailed in Appendix I of this AC is an aircraft level operational evaluation. Depending on the circumstances, this evaluation may be combined with the installation evaluation detailed in Appendix C of this AC. An associated operational evaluation checklist is provided in Appendix J of this AC.
  • (c) The air operator is responsible for ensuring that these evaluations are conducted. This includes discussing with Transport Canada the content, methodology and level of Transport Canada involvement. These evaluations will normally be conducted by individuals with the requisite skill set hired by the air operator. If the air operator does not have individuals with the necessary skill set to conduct these evaluations, they may use an external individual or organization having the appropriate skills.

8.0 Information Management

• (1) Not applicable.

9.0 Document History

• (1) Advisory Circular (AC) 700-020, Issue 01, RDIMS 4252990(E), 4954844(F), dated 2011-08-03 — Electronic Flight Bags.
• (2) AC 700-020, Issue 02, RDIMS 8033165(E), 8033180(F), dated 2012-12-19 — Electronic Flight Bags.

10.0 Contact Office

For more information, please contact:

Chief, Commercial Flight Standards (AARTF)

Fax: 613-990-6215
E-Mail: AARTInfoDoc@tc.gc.ca

Suggestions for amendment to this document are invited, and should be submitted to the following email address: AARTInfoDoc@tc.gc.ca

Original signed by

Robert Sincennes
Director, Standards
Civil Aviation
Transport Canada

Appendix A — Examples of “Type A” Electronic Flight Bags Applications

Type A software applications:

• (a) are Electronic Flight Bags (EFB) applications whose malfunction or misuse have no safety effect;
• (b) generally do not replace any paper, system or equipment as required under the Civil Aviation Regulations (CARs);
• (c) do not require approval from Transport Canada, Civil Aviation (TCCA) for use on an EFB;
• (d) do not require compliance with RTCA DO-178() - Software Considerations in Airborne Systems and Equipment Certification, and
• (e) are to be installed for and included in the evaluations described in paragraphs 6.1 and 6.2 of this AC, as applicable. These evaluations include demonstrating that the EFB operating system and hosted application software meet the criteria for the appropriate intended function and do not provide false or hazardously misleading information. A checklist for the evaluation of installed software applications is provided in Appendix F of this AC.

Below is a non-exhaustive list of examples of Type A EFB applications.

• Airport diversion policy guidance, including a list of Special Designated Airports and/or approved airports with emergency medical service (EMS) support facilities;
• Flight Management System/Flight Management and Guidance System problem report forms;
• Aircraft parts manuals;
• Service bulletins/published Airworthiness Directives, etc.;
• Air Transport Association (ATA) 100 format maintenance discrepancy write-up codes;
• Required VHF Omnidirectional Range (VOR) check records;
• Minimum Equipment Lists (MEL);
• Configuration Deviation Lists (CDL);
• Nonessential Equipment and Furnishings (NEF) lists;
• Airport-specific rules and regulations;
• Airport/Facility Directory (A/FD) data (e.g., fuel availability, LAHSO distances for specific runway combinations, etc.); Canada Flight Supplement (CFS) in Canada
• Noise abatement procedures for arriving and departing aircraft;
• International Operations Manuals, including regional supplementary information and International Civil Aviation Organization (ICAO) differences;
• Aeronautical Information Publications (AIP);
• Aeronautical Information Manual (AIM);
• Pilot flight and duty-time logs;
• Flight crew required rest logs;
• Flight crew qualification logs;
• Captain’s report (i.e., captain’s incident reporting form);
• Flight crew survey forms (various);
• EMS reference library (for use during medical emergencies);
• Trip scheduling and bid lists;
• Aircraft’s captain’s logs;
• Antiterrorism profile data;
• Hazardous Materials (HAZMAT)/oxidizer look-up tables;
• Customs declaration and agriculture inspection/clearance form;
• Special reporting forms, such as near mid-air collision (NMAC) reports, National Aeronautics and Space Administration’s (NASA) Aviation Safety Reporting System (ASRS), bird and wildlife encounters, owner-initiated Service Difficulty Reports (SDR), etc.;
• Incidents of interference to aircraft electronic equipment from devices carried aboard aircraft;
• Current fuel prices at various airports;
• Realistic training modules, including “PC at home” training applications, “off-duty” training materials review, and pre-flight “mission” rehearsals;
• Check pilot and flight instructor records;
• Airline policies and procedures manuals;
• Look-up and completion of various reporting forms, e.g., company-specific forms, NASA’s ASRS reports, NMAC reports, wildlife strike and hazard reports, etc.;
• Pilot-in-Command (PIC) currency requirements;
• Passenger information requests—some are directed to the gate or to the agent meeting the flight (e.g., special meal requests, wheel chair requirements, unaccompanied minors, gate information for connecting flights, flights being held for connecting passengers, etc.);

Appendix B — Examples of “Type B” Electronic Flight Bags Applications

Type B software applications:

• (a) are applications whose malfunction or misuse are limited to a minor failure condition;
• (b) do not substitute for, or replace any system functionality required by airspace requirements, technical airworthiness or operational regulations;
• (c) do not require compliance with RTCA DO-178() -- Software Considerations in Airborne Systems and Equipment Certification;
• (d) may include dynamic, interactive applications that can manipulate data and the presentation of that data;
• (e) may display own-ship position for situational awareness purposes;
• (f) are to be installed for and included in the evaluations described in paragraphs 6.1 and 6.2 of this AC. These evaluations include demonstrating that the EFB operating system and hosted application software meet the criteria for the appropriate intended function and do not provide false or hazardously misleading information;
• (g) should be evaluated in accordance with the guidance in Appendix E, Section 5 and Appendix F, and
• (h) Particular attention must be given to the Type B software applications that provides interactive performance applications. These software applications should be evaluated to ensure that the possibility of entering incorrect data into performance calculations is minimised.

Below is a non-exhaustive list of examples of Type B EFB applications.

• Aircraft Flight Manuals (AFM) and Aircraft Flight Manual Supplements (AFMS);
• Flight Operations manuals (FOM);
• Flight Crew Operating Manuals (FCOM);
• Company Standard Operating Procedures (SOP);
• Special Authorizations / Special Approvals;
• For smaller aircraft, Pilot Operating Handbooks (POH), including POH section IX supplements;
• Flight Attendant Manuals;
• Maintenance manuals;
• Aircraft flight log and servicing records;
• Autopilot approach and autoland records;
• Aircraft maintenance reporting manuals;
• Aircraft performance data (fixed, non-interactive material for planning purposes);
• Take-off, en route, approach and landing, missed approach, go-around, performance calculations. Data derived from algorithmic data or performance calculations based on software algorithms;
• Power settings for reduced thrust settings;
• Runway limiting performance calculations;
• Cost index modeling;
• Master flight plan/updating;
• Interactive Plotting for Class II navigation;
• Mission rehearsals;
• Weight and balance calculations;
• Maintenance discrepancy sign-off logs;
• Cabin maintenance discrepancy reporting forms;
• Non-interactive electronic approach charts in a pre-composed format from accepted sources;
• Panning, zooming, scrolling, and rotation for approach charts;
• Pre-composed or dynamic interactive electronic aeronautical charts (e.g., en route, area, approach, and airport surface maps) including, but not limited to, centering and page turning. The use of own ship position as an aid to situational awareness and is not intended for primary navigation;
• Electronic checklists, including normal, abnormal, and emergency. See the current version of FAA AC 120-64, Operational Use & Modification of Electronic Checklists, for additional guidance. EFB electronic checklists cannot be interactive with other aircraft systems;
• Applications that make use of the Internet and/or other Aircraft Operational Communications (AOC);
• AOC or company maintenance-specific data links to collect, process, and then disseminate data for uses such as spare parts and budget management, spares/inventory control, unscheduled maintenance scheduling, etc. (Maintenance discrepancy logs need to be downloaded into a permanent record at least weekly);
• Weather and aeronautical data;
• Cabin-mounted video and aircraft exterior surveillance camera displays;
• Published (graphical) pilot Notices to Airmen (NOTAM);
• Aircraft’s CAT II/CAT III landing records;
• Oceanic navigation progress logs;
• Maintenance personnel sign-off of discrepancy form;
• Aircraft operating and information manuals (performance information, weight and balance, systems, limitations, etc.);
• Cabin maintenance write-ups. (Maintenance discrepancy logs need to be downloaded into a permanent record at least weekly);
• Approved electronic signature using public/private key technology (PKI);
• De-icing or, Hold Over Time (HOT) Tables and/or procedures;
• Cockpit observer briefing cards;
• Emergency Response Guidance for Aircraft Incidents Involving Dangerous Goods (ICAO Doc 9481-AN/928);
• Airport performance restrictions manual (such as a reference for take-off and landing performance calculations); and
• Other aircraft performance data, including specialized performance data for use in conjunction with advanced wake vortex modeling techniques, land-and-hold-short operations (LAHSO) predictions, etc. (fixed, non-interactive material for planning purposes).

Appendix C — Electronic Flight Bags Classification Matrix

This table provides criteria to aid in determining the involvement of TCCA, operators, installers and manufacturers in EFB evaluation and approval.

Table 1: EFB Classification Matrix

Hardware	EFB Software Applications	TCCA Aircraft Certification Involvement	TCCA Operations Involvement	Operator/Installer/Manufacturer Involvement
Portable	Type A Type B	For mounting power supply and connectivity provisions.	POI review and approval of COM	Evaluation of human factors and functionality evaluation as specified in this AC and other TCCA advisory material.
Installed	Type A Type B (Partitioned from Types A and B)	For all aspects including installation.	POI review and approval of COM	Evaluation of human factors and functionality for Type A and B software as specified in this AC and other TCCA advisory material.

Appendix D — Electronic Flight Bags Evaluation Process

This Appendix provides details of the evaluation process required prior to the use of new EFB hardware and/or software on an aircraft. The associated checklists specified in Appendices E, F, and G should be completed for each application to be installed in the EFB. The evaluation should consider the aspects below.

Hardware

• (1) Stowage
  • (a) Stowage is required for Portable EFBs units as Installed EFB devices are by definition integrated into the aircraft.
  • (b) A stowage area with a securing mechanism for these EFBs is recommended for storage of portable units when they are not in use. Stowage provisions should be readily accessible by the crew in fli ght and should not cause any obstruction or hazard during foreseeable aircraft operations. EFB systems that are not secured in a mounting device during use should be designed and used in a manner that prevents the device from jamming flight controls, damaging flight deck equipment, or injuring flight crew members should the device move about as a result of turbulence, manoeuvring, or other action.
• (2) Viewable Stowage
  • (a) A portable EFB may be used in all phases of flight provided that it is secured in an existing provision viewable to the pilot (e.g. kneeboards, suction cups, etc.)
• (3) Cabling
  • (a) Certification is required for any cabling associated with portable EFBs. The cabling should not hang loosely in a way that compromises task performance or safety. Flight crew members should be able to easily secure cables out of the way during aircraft operations. Cables should be of sufficient length to perform the intended function. Cables too long or too short could present an operational or safety hazard.
• (4) Connections
  • (b) Portable EFB
    • (i) Portable EFB systems may connect to aircraft power through a certified power source. An electrical load analysis should be conducted to replicate a typical EFB system to ensure that powering or charging the EFB will not adversely affect other aircraft systems and that power requirements remain within power-load budgets. A means (other than a circuit breaker) for the flight crew member to de-power the EFB power source or system charger should be provided;
    • (ii) Portable EFB systems may have read only data connectivity to other aircraft systems. The design of the connection should ensure that there is no possibility of the EFB affecting the aircraft systems from which data is being acquired.
  • (c) Installed EFB
    • (i) Installed EFBs must be approved by TCCA Aircraft Certification and meet all applicable certification requirements.
• (5) Mounting Provisions
  • (a) Portable EFBs are not mounted to the aircraft and Installed EFBs are permanently installed. Mounting provisions must be approved by TCCA Aircraft Certification and must meet all applicable certification requirements.
  • (b) The mounting device (or other securing mechanism) that attaches or allows mounting of the EFB system should ensure that the EFB is positioned in a way that it does not obstruct visual or physical access to aircraft controls and/or displays, flight crew member ingress or egress, or external vision. The design of the mount should allow the user easy access to the EFB controls and a clear view of the EFB display while in use. The following design practices should be considered:
    • (i) The mount and associated mechanism should not impede the flight crew member in the performance of any task (normal, abnormal, or emergency) associated with operating any aircraft system.
    • (ii) Mounting devices should be able to lock in position easily. Selection of positions should be adjustable enough to accommodate a range of flight crew member preferences. In addition, the range of available movement should accommodate the expected range of users’ physical abilities (i.e. anthropometric constraints). Locking mechanisms should be of the low-wear type that will minimize slippage after extended periods of normal use. Crashworthiness considerations will need to be considered in the design of this device. This includes the appropriate restraint of any device, when in use.
    • (iii) A provision should be provided to secure, lock, or stow the mount in a position out of the way of flight crew member operations when not in use.
    • (iv) An unsafe condition must not be created when attaching any EFB control yoke attachment/mechanism or mounting device. For example, the weight of the EFB and mounting bracket combination may affect flight control system dynamics, even though the mount alone may be light enough to be insignificant. The equipment when mounted and/or installed should not present a safety-related risk or associated hazard to any flight crew member. A means to store or secure the device when not in use should be provided. Additionally, the unit (or its mounting structure) should not present a physical hazard in the event of a hard landing, crash landing, or water ditching. EFBs and their power cords should not impede emergency egress.
• (6) Position
  • (a) If it has a stowed position the EFB should be easily accessible when stowed. When the EFB is in use and is intended to be viewed or controlled, it should be within 90 degrees on either side of each pilot’s line of sight. If an EFB is being used to display flight critical information such as for navigation, terrain and obstacle warnings that require immediate action, take-off and landing V-speeds, or for functions other than situational awareness, then such information needs to be in the pilot’s primary field of view. This requirement does not apply if the information is not being directly monitored from the EFB during flight. For example, an EFB may generate take-off and landing V-speeds, but these speeds are used to set speed bugs or are entered into the AFMS, and the airspeed indicator is the sole reference for the V-speeds. In this case, the EFB need not be located in the pilot’s primary field-of-view. A 90-degree viewing angle may be unacceptable for certain EFB applications if aspects of the display quality are degraded at large viewing angles (e.g., the display colors wash out or the displayed color contrast is not discernible at the installation viewing angle). In addition, consideration should be given to the potential for confusion that could result from presentation of relative directions (e.g., positions of other aircraft on traffic displays) when the EFB is positioned in an orientation inconsistent with that information. For example, it may be misleading if own aircraft heading is pointed to the top of the display and the display is not aligned with the aircraft longitudinal axis. Each EFB should be evaluated with regard to these requirements. See Chapter § 523.1321 of the AWM and section 525.1321 of the CARs.
• (7) Reflection
  • (a) In the position in which it is intended to be used, the EFB should not produce objectionable glare or reflections that could adversely affect the pilot’s visual environment.
• (8) Lighting
  • (a) Users should be able to adjust the screen brightness of an EFB independently of the brightness of other displays on the flight deck. In addition, when automatic brightness adjustment is incorporated, it should operate independently for each EFB in the flight deck. Buttons and labels should be adequately illuminated for night use. Consideration should be given to the long-term display degradation as a result of abrasion and aging.
• (9) Readability
  • (a) Text displayed on the EFB should be legible to the typical user at the intended viewing distance(s) and under the full range of lighting conditions expected on a flight deck, including use in direct sunlight.
• (10) Controls
  • (a) All controls should be properly labeled for their intended function;
  • (b) All controls should be within reach of the appropriate crewmember seated normally on the fight deck;
  • (c) In choosing and designing input devices such as keyboards or cursor-control devices, applicants should consider the type of entry to be made and flight deck 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 intended application function as well as for the flight deck environment.
• (11) Disabling of installed EFBs
  • (a) For installed EFBs there should be a means other than a circuit breaker to disable the EFB in the event of unwanted operation such as continuous flashing. Circuit breakers may not be used as switches.
• (12) Interference with Other Aircraft Systems
  • (a) Portable EFB systems should demonstrate that they meet appropriate industry-adopted environmental qualification standards for radiated emissions for equipment operating in an airborne environment. Any Portable EFB used in aircraft flight operations should be demonstrated to have no adverse impact on other aircraft systems (non-interference). The manufacturer, installer, or operator may accomplish the testing and validation to ensure proper operation and non-interference with other aircraft systems. Possible interference when portable EFB systems are moved about in the cockpit should be addressed. Guidance for conducting interference testing of Transmitting Portable Electronic Devices may be found in RTCA DO-294()—Guidance on Allowing Transmitting Portable Electronic Devices (T-PEDs) on Aircraft and RTCA DO-363() – Guidance for the Development of Portable Electronic Devices (PED) Tolerance for Civil Aircraft.
• (13) Rapid Depressurization Testing
  • (a) Testing for rapid depressurization may need to be performed to provide some level of assurance of functional capability during a decompression event. However, since many Portable EFB were originally commercial off-the-shelf (COTS) electronic systems adopted for aviation use, testing done on a specific EFB model configuration may be applied to other aircraft installations and these generic environmental tests need not be duplicated. It is the responsibility of the operator seeking approval to provide documentation that these tests have been accomplished and comply with the requirement of RTCA DO-160 - Environmental Conditions and Test Procedures for Airborne Equipment, Section 4, Temperature and Altitude for rapid decompression testing up to the maximum operating altitude of the aircraft in which the EFB is to be used. Similarity of a particular EFB make and model to a unit already tested may be used to comply with this requirement. It is the responsibility of the operator to provide the rationale for the similarity.

Hardware with installed software

• (1) Responsiveness of Application
  • (a) The system should provide feedback to the user when user input is accepted. If the system is busy with internal tasks that preclude immediate processing of user input (e.g., calculations, self-test, or data refresh), the EFB should display a “system busy” indicator (e.g., clock icon) to inform the user that the system is occupied and cannot process inputs immediately. The timeliness of system response to user input should be consistent with an application’s intended function. The feedback and system response times should be predictable to avoid flight crew distractions and/or uncertainty.
• (2) Readability
  • (a) Text size and font for each application should ensure readability at the intended viewing distance and page layout should ensure clarity and prevent any ambiguity.
  • (b) 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. This should be evaluated based on the application and intended operational function. If there is a cursor, it should be visible on the screen at all times while in use.
  • (c) If the electronic document application supports multiple open documents, or the system allows multiple open applications, 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. Under non-emergency, normal operations, 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 deck applications are running and switch to any one of these applications easily. 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—other than differences associated with the progress or completion of processing performed in the background.
• (3) Colours
  • (a) For any EFB system, EFB messages and reminders should meet the requirements in sections 523.1322 or 525.1322 of the CARs, as is appropriate for the intended aircraft. While the regulations refer to lights, the intent should be generalized to extend to the use of colors on displays and controls. That is, the color “red” should be used only to indicate a warning level condition. “Amber” should be used to indicate a caution level condition. Any other color may be used for items other than warnings or cautions, providing that the colors used differ sufficiently from the colors prescribed to avoid possible confusion.
• (4) Messages
  • (a) EFB messages and reminders should be integrated with (or compatible with) presentation of other flight deck system alerts. EFB messages, both visual and auditory, should be inhibited during critical phases of flight. Flashing text or symbols should be avoided in any EFB application. Messages should be prioritized and the message prioritization scheme evaluated and documented. Additionally, during critical phases of flight, required flight information should be continuously presented without un-commanded overlays, pop-ups, or pre-emptive messages, except those indicating the failure or degradation of the current EFB application. However, if there is a regulatory or Technical Standard Order (TSO) requirement that conflicts with the recommendation above, those requirements supersede this guidance.
• (5) Interface
  • (a) The EFB user interface should provide a consistent and intuitive user interface within and across various EFB applications. The interface design, including, but not limited to, data entry methods, color-coding philosophies, and symbology, should be consistent across the EFB and various hosted applications. These applications should also be compatible with other flight deck systems.
• (6) Data Entry
  • (a) If 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 and application software 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) Possibility for Error/Confusion
  • (a) The system should be designed to minimize the occurrence and effects of flight crew error and maximize 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. Data entry methods, color-coding philosophies, and symbology should be as consistent as possible across the various hosted EFB applications. These applications should also be compatible with other flight deck systems. Entered data should be displayed with the associated results of each calculation.
• (8) Workload
  • (a) EFB software should be designed to minimize flight crew workload and head-down time. Complex, multi-step data entry tasks should be avoided during take-off, landing, and other critical phases of flight. An evaluation of EFB intended functions should include a qualitative assessment of incremental pilot workload, as well as pilot system interfaces and their safety implications. If an EFB is to be used during critical phases of flight, such as during take-off and landing or during abnormal and emergency operations, its use should be evaluated during simulated or actual aircraft operations under those conditions.
• (9) Optional – Software Development Criteria
  • (a) Any person considering or involved with the design of complex software applications for use on EFBs should consider the material contained in Appendix K of this AC.

Appendix E — Electronic Flight Bags Evaluation Checklist

Item	EFB Evaluation Checklist Items	Acceptable Yes/No/NA
1	Stowage, When Not in Use (if applicable)
	Is stowage readily accessible in flight?
	Has it been determined that the stowage does not cause obstruction during foreseeable aircraft operations? (Certification)
	Has it been determined that the stowage does not cause any hazard during foreseeable aircraft operations? (Certification)
2
	Viewable Stowage (e.g.: Suction cup mounts)
	Is the make and model of the suction mount clearly specified?
	Have the acceptable locations for securing the mounting device been adequately defined?
	Have the effects of decompression on the effectiveness of the securing device been adequately considered?
	Have instructions been provided for the securing and removal of the mounting device?
	Has it been established that if the mounted EFB becomes unsecured for whatever reason, that it will not: Jam the flight controls (e.g. rudder pedals, tiller, yoke), Damage flight deck equipment, or Injure flight crew members?
	Have maintenance requirements and instructions for long term care of the mounting device been provided to ensure the continued effectiveness of the securing device?
	Have maintenance requirements and instructions for long term care of the window, to which the suction cups are secured, been considered or modified to account for the suction cup mounting?
	Given that the security of the suction cup mount cannot be ensured during a decompression event, do the operator’s procedures and QRH adequately address this emergency condition?
3
	Cabling
	If the EFB has associated cabling, is it long enough to perform the intended function?
	Is it short enough that it will not hang loosely and compromise task or safety?
	Is there a means to secure the cable?
4
	Electrical Power Sources
	Is the EFB Power Source certified and appropriately labeled?
	If an updated electrical load analysis is required, has it been completed satisfactorily?
	Is there a means other than a circuit breaker to disable the EFB in the event of unwanted operation? (Certification)
	Did the design consider sources of electrical power and independence?
	Was useful battery life established?
	Was battery replacement interval identified?
	If Lithium batteries are used, were use of Lithium battery safety concerns adequately addressed?
5
	Data Connection
	Has the data connection been certified? (Certification)
	Has it been determined that the EFB cannot affect other aircraft systems? (Certification)
	Is the aircraft systems and network security acceptable? (Certification)
6
	Mounting
	Has the mounting device and its crashworthiness been certified? (Certification)
	Has it been determined that the mounted EFB does not obstruct aircraft displays? (Certification)
	Has it been determined that the mounted EFB does not obstruct aircraft controls? (Certification)
	Has it been determined that the mounted EFB does not impede ingress or egress? (Certification)
	Has it been determined that the EFB and its mount do not impede visibility of other aircraft, taxiway edges, airport signage, ground equipment and marshallers? (Certification)
	Has it been determined that the EFB and its mount do not impede visibility of other aircraft or obstacles in flight? (Certification)
	Has it been determined that the mounted EFB does not impede egress? (Certification)
	Does the mounted EFB allow easy access to the EFB controls? (Certification)
	Does the mounted EFB provide a clear view of the EFB displays? (Certification)
	Is the mounting device easily adjustable to accommodate flight crew member preferences? (Certification)
	Can the mounting device easily be locked in place? (Certification)
	Can the mounting device be stowed out of the way of crewmember operations when not in use, if required? (Certification)
	Does the mounted EFB present any hazard to any crewmember, or obstruct access to any required control or equipment (including oxygen masks)? (Certification)
	If the mounting is on the control yoke, have flight control system dynamics been considered? (Certification)
6
	Position
	Is the EFB within 90 degrees on each side of the pilot’s line of sight?
	Is it to be handheld and/or placed on the lap? (Note that if it is to be used during critical phases of flight, it must be secured to a kneeboard, viewable stowage device or aircraft mounting device).
	Has it been demonstrated that the potential for confusion that could result from presentation of relative directions when the EFB is positioned in an orientation inconsistent with that information is acceptable?
	Can the EFB be used without obstructing controls or instruments? (Certification)
7
	Reflections
	Will the EFB cause any unacceptable reflections or glare in the intended use position? (Certification)
8
	Lighting
	Is the display brightness adequately adjustable for day/night operations?
	Are controls and control labels adequately lit?
9
	Readability
	Is display readable in all foreseeable lighting conditions including direct sunlight?
10
	Controls
	Are all controls clearly labeled for their intended function?
	Are the controls suitable for use in the cockpit?
	Are the controls useable in turbulence?
11
	Electromagnetic Interference With Other Aircraft Systems
	Has EFB been shown to be EMC with the aircraft?
	Have ground tests been conducted to demonstrate non-interference with other aircraft systems? (Certification)
	Have flight tests been conducted to demonstrate non-interference with other aircraft systems? (Certification)
	Has non-interference with other aircraft systems been verified with movement of the EFB in the cockpit?
	Has the aircraft been shown to be PED tolerant? (Certification)
13
	Rapid Decompression Testing
	Has documentation of rapid decompression testing of the EFB itself been provided?

Comments

Limitations or procedures required for operational use

Appendix F — Electronic Flight Bag Software Applications Evaluation Checklists

Item	Installed Software	Acceptable Yes/No/NA
1	Responsiveness of Application
	Is feedback provided for user input?
	Is there an indication that the system is busy if the system cannot process inputs immediately?
	Is system response time predictable and consistent with intended function?
2
	Readability
	Does the text size and font ensure readability at the intended viewing distance?
	Does the page layout provide sufficient clarity?
	Is the cursor always visible?
	Is indication of the active application/document provided?
	Is it easy to switch between applications?
3
	Colour Usage
	Does the use of colour meet Chapter 523.1322/525.1322 of the AWM as appropriate to the aircraft? Is red only used to indicate a warning condition? Is amber only used to indicate a caution condition?
4
	Message Compatibility
	Is there a means to inhibit visual and auditory messages during critical phases of flight?
	Is the application free of flashing text or symbols?
	Are messages prioritized?
	Has the prioritization scheme been documented?
5
	Interface
	Is the user interface consistent and intuitive?
	Is the user interface consistent with other EFB applications?
	Are the applications consistent with other flight deck systems?
6
	Data Entry
	Is the EFB prevented from accepting data of incorrect format or type?
	Does the EFB provide error messages for incorrect data entries?
	Are input errors detected at the earliest possible point in the input sequence?
7
	Possibility for Error/Confusion
	Does the system minimize the occurrence of flight crew member error?
	Does the system maximize the possibility of error detection?
	Is entered data displayed with the results of each calculation?
8
	Workload
	Has the effect of the EFB on pilot workload been evaluated in all applicable phases of flight?
	Has the effect of the EFB on pilot workload been evaluated under applicable abnormal and emergency operations?

Comments

Limitations or procedures required for operational use

Appendix G — Operational Evaluation at the Corporate/Company Level

This Appendix provides details of the evaluation process at the corporate/company level which is required prior to operational phase in of EFB hardware and/or software on company aircraft. The focus of this evaluation is for the air operator to consider all aspects which may be affected by the incorporation of EFB into flight operations.

The scope of the evaluation may be greater than that provided below, dependent on the actual implementation. However, as a minimum the air operator should consider the items listed below. An associated checklist is contained in Appendix H of this AC. The operator is encouraged to create customized checklists as required.

EFB Administrator

• (1) The operator should designate an EFB Administrator (EFBA) who should be suitably qualified and trained and provided with adequate resources.

Crew Procedures

• (1) Clear limitations and crew procedures should be provided and documented for all phases of flight. A system description and operating philosophy should be included.
• (2) Procedures should:
  • (a) Be properly integrated with existing Standard Operating Procedures (SOPs);
  • (b) Contain suitable crew crosschecks for verifying safety critical data;
  • (c) Mitigate and/or control any additional workload associated with the EFB;
  • (d) Provide contingency procedures for total or partial EFB failure;
  • (e) Cover system reboots, lock-ups and recovery from incorrect crew actions; and
  • (f) Include a requirement to verify the revision status of software.

Operational Risk Analysis

• (1) Operators should determine appropriate procedures to eliminate, reduce, or control risks associated with identified failures in the EFB system.
• (2) These procedures will generally be the result of an operational risk analysis conducted by the operator that considers:
  • (a) Total and partial failures of the EFB;
  • (b) Loss of data;
  • (c) Corrupt/erroneous outputs; and
  • (d) MEL dispatch condition.
• (3) The results of such an analysis may highlight the need for more than one EFB system for redundancy. It is also possible that the second EFB may have to be a different model (dissimilar system) to minimise common mode failures.

Training Program

• (1) The operator should establish suitable training programs for ground staff and crew members. Once it is established, the training program must be evaluated to determine that:
  • (a) The program is fully documented;
  • (b) The training methodology matches the level of knowledge and experience of the participants;
  • (c) The operator has assigned adequate resources to deliver the training;
  • (d) Adequate EFB and/or EFB simulation equipment has been provided;
  • (e) Human factors and cockpit resource management are included in the training;
  • (f) The training material matches both the EFB equipment status and the published procedures;
  • (g) The training program incorporates training for system changes and upgrades; and
  • (h) If applicable, the training program maintains crew proficiency in non-EFB (e.g.: paper charts) procedures.

Hardware Management Procedures

• (1) The operator should establish documented procedures for the control of hardware and component stocks covering removal, repair, replacement, re-installation and maintenance.

Software and Management Procedures

• (1) The operator should establish documented procedures for the control of installed software. These procedures must include:
  • (a) A clear definition of who has access rights to install or modify software;
  • (b) Adequate controls to prevent user corruption of operating systems and software;
  • (c) Adequate security measures to prevent viruses and unauthorized user access.

Data Management Procedures

• (1) The operator should establish documented data management procedures. These procedures must:
  • (a) Interface satisfactorily with procedures used by external data providers;
  • (b) Define access rights for users and administrators;
  • (c) Provide adequate controls to prevent user corruption of data.

System Security

• (1) The required level of EFB security depends on the criticality of the used functions (e.g. an EFB which only holds a list of fuel prices may require less security than an EFB used for performance calculations).
• (2) The EFB system (including any means used for its updating) shall be protected from unauthorised access or intervention (e.g. malicious software). The EFB Administrator shall ensure that adequate security procedures and measures are in place to protect the entire system at both the software and hardware levels. These procedures and measures shall ensure that prior to each flight the EFB operational software works as specified and the EFB operational data is complete and accurate.
• (3) The EFB system shall ensure that the EFB does not accept a data load that contains corrupted contents. Adequate measures shall be in place for compilation and secure distribution of the data to the aircraft. The procedures should be transparent, easy to understand, to follow and to oversee:
  • (a) when not in use, physical security (e.g. locks, safe, locked room) of hardware shall be implemented for portable EFBs;
  • (b) portable EFB platforms shall be subject to allocation tracking to specific aircraft and/or persons;
  • (c) special consideration shall be given to the risks associated with input ports especially those using widely known protocols and/or where internet access is sought; and
  • (d) the operator shall use technologies and/or procedures to assure that unauthorised content cannot enter the EFB system through the use of physical media.
• (4) The EFB system shall be protected from inadvertent or malicious changes to, and adverse impacts upon, systems, networks, hardware, software and data in the Aircraft Control Domain (i.e. impacts/interfaces with the certified aircraft systems) and in the Airline Information Services Domain (i.e. impacts/interfaces with the airline operator systems) from access points within the Passenger Information and Entertainment Services Domain (e.g. Access from internal WiFi).
• (5) The EFB Administrator shall ensure EFB security threats from unauthorized sources are identified and assessed, and that effective EFB security protection strategies are implemented to protect the aircraft from all adverse impacts on safety, functionality, and continued airworthiness.
• (6) Appropriate procedures shall be established to permit the EFB Administrator to determine whether an unsafe condition exists following attempted access to systems and networks by unauthorized sources.
• (7) Beyond the level of security required to assure that the EFB can properly perform its intended functions, the level of security ultimately required depends on the capabilities of the EFB. The system safety and security defences shall be at a minimum comprised of the following:
  • (a) Individual system firewalls;
  • (b) Clustering of systems with similar safety standards into domains;
  • (c) Data encryption & authentication;
  • (d) Virus scans;
  • (e) Keeping the OS up to date;
  • (f) Initiating air/ground connections only when required and always from the aircraft;
  • (g) ‘Whitelists’ for allowed Internet domains;
  • (h) Virtual Private Networks (VPNs);
  • (i) Granting of access rights on a need-to-have basis;
  • (j) Troubleshooting procedures should consider as well security threats as potential root cause of EFB misbehaviour, and responses should be developed to prevent future successful attacks when relevant;
  • (k) Virtualisation;
  • (l) Forensic tools and procedures; and
  • (m) The EFB administrator should not only keep the EFB system, but also his/her knowledge about security of EFBs systems up to date.

Use of Own-Ship Positio EFB Own-Ship Functionality

• (1) Own-ship functionality should only be used for strategic purposes (e.g. situational awareness) and is not to be used as a tool for surface manoeuvring or airborne navigation. The display of own-ship position for strategic use is acceptable provided the following are addressed and mitigated:
  • (a) EFB applications may display an EFB own-ship symbol for both in-flight and surface use. Operators shall minimize the risk of misleading position during in-flight use.
  • (b) The flight crew must be able to distinguish between the installed avionics display and the supplemental or “secondary” EFB display. This concept is straightforward for portable EFBs, but for installed EFB displays, further evaluation of the installed avionics display is required under type design (reference AC 20-173, paragraph 5.d and AC 25-11, paragraph 5.10).

EFB Own-Ship Position Requirements

• (1) Positional Awareness. EFB own-ship position is limited to serve as an aid to positional awareness.
• (2) Position Source Selection. It is recommended to use position data from an installed GNSS source. Position data from a portable GNSS source is acceptable provided it supports the application requirements and it works as intended in the aircraft environment.
• (3) Own-ship Position displayed on Installed Displays. Any depictions of EFB own-ship for in-flight use on installed displays must be considered via an installation approval for the display under type design. The installation under type design will consider security, differentiation, and placement, as required.
• (4) Own-ship Directionality. Change own-ship symbol to a non-directional (e.g. circular) depiction when heading is not available or cannot be calculated based on GNSS data.
• (5) Own-ship GNSS Data Stream. Remove own-ship symbol if the GNSS data stream stops. This will guard against a "frozen" own-ship condition caused by position source signal or power loss and removal should occur in a timely manner.
• (6) Own-ship Surface Use Accuracy. For airport map applications, the applicant should choose a database with an accuracy of 5 meters or less. For airports where such data is not currently available, a database accuracy of 30 meters can still be operationally useful. If the database accuracy exceeds 30 meters, do not display EFB own-ship position.
• Note 1: Applicants should contact their EFB airport map application provider to obtain the accuracy of their database. This information is usually found in documentation supporting the EFB airport map application.
• (7) Map Zoom. The application will need to indicate the current level of zoom on the display. The design should ensure the zoom level is compatible with the position accuracy of the own-ship symbol.
• (8) Electronic Map and Aeronautical Chart Standards. The current editions of the following standards are recommended guidance for designing EFB own-ship depiction on airborne EFB applications and electronic aeronautical charts:
  • • RTCA/DO-257, Minimum Operational Performance Standards for Depiction of Navigational Information on Electronic Maps.
  • • RTCA/DO-272, User Requirements for Aerodrome Mapping Information.
  • • RTCA/DO-201, User Requirements for Aeronautical (Navigation) Information.

Training Requirements for Use of Own-Ship Position

• (1) Training to use EFB own-ship position on EFB applications must emphasize the limitations of this supplemental tool for use by the flight crew. Training must include the following:
  • (a) EFB own-ship position is for positional awareness only. Crews may not use EFB own-ship position to maneuver the aircraft.
  • (b) The flight crew’s reference for maneuvering the aircraft on the ground is visual identification of the airport, taxiway, and runway signage and markings.
  • (c) The flight crew’s reference for maneuvering the aircraft in the air is the installed primary flight and navigational displays. When a conflict occurs between the primary flight navigation displays and the EFB, the flight crews must utilize the primary displays.
  • (d) Reporting positioning or database errors when visual checks reveal display discrepancies.

Company Documentation Requirements

• (1) The company’s Standard Operating Procedures shall include the following statement:
• “This EFB is not certified as a navigation system. Transport Canada has not assessed the EFB for performance or reliability of the platform hardware or software (including GPS functionality).”

Appendix H — Operational Evaluation Checklist — Corporate/Company Level

Item	Operational Evaluation Checklist – Corporate/company level	Acceptable Yes/No/NA
1	EFB Administrator
	Is the nominated EFBA suitably qualified and trained?
	Do the listed responsibilities match the requirements of the system?
	Are there adequate resources assigned to the EFBA function?
2
	Crew Procedures
	Are there appropriate procedures for all phases of flight? Are the procedures clearly presented, suitably illustrated and readily understood?
	Is there a clear description of the system, its operating philosophy and operational limitations?
	Has the information in the Aircraft Flight Manual Supplement (AFMS) been incorporated into the company Standard Operating Procedures (SOPs)?
	Have crew procedures for EFB operation been integrated with existing SOPs?
	Are there suitable crew cross-checks for verifying safety-critical data?
	Is any additional workload mitigated/controlled?
	Are there contingency procedures for total or partial EFB failure?
	Do the procedures cover system re-boots, lock-ups and recovery from incorrect crew actions?
	Do crew procedures include a requirement to verify the revision status of software and data?
3
	Operational Risk Analysis
	Has the operator considered total and partial failures of the EFB?
	Has the operator considered loss of data and corrupt/erroneous outputs?
	Has the impact of the EFB on the MEL been assessed?
	In cases where an operator is operating a number of variants, has the impact on training/checking and currency been assessed?
4
	Training Program
	Are flight crew members and (where applicable) ground staff training programs fully documented?
	Is the training methodology matched to the participants’ level of experience and knowledge?
	Has the operator assigned adequate resources (time/personnel/facilities) for training?
	Is there access to actual or simulated EFB equipment for interactive training?
	Does the training material match the EFB equipment status and published procedures?
	Does the training program include human factors/CRM in relation to EFB use?
	Does the training program incorporate training for system changes and upgrades?
	In cases where an operator is operating a number of variants of the same aircraft, has the impact on training/checking and currency been assessed?
	Is there a published recurrent training, checking and currency program?
	If applicable, does the training program maintain crew proficiency in non-EFB procedures (e.g. paper charts)
5
	Hardware Management Procedures
	Are there controlled documented procedures for the control of hardware and component stocks?
	Do the procedures include repair, replacement and maintenance of EFB equipment and peripherals?
6
	Software Management Procedures
	Are there documented procedures for the control of installed software?
	Are the access rights for personnel to install or modify software components clearly defined?
	Are there adequate controls to prevent user corruption of operating systems & software?
	Are there adequate security measures to prevent system degradation, viruses, and unauthorized access?
	Are procedures defined to track database expiries and obtain and install monthly chart database updates?
7
	Data Management Procedures
	Are there documented procedures for the control and management of data?
	How do the procedures interface with procedures used by external data providers?
	Are the access rights for users and administrators to manage data clearly defined?
	Are there adequate controls to prevent user corruption of data?
8
	Security Procedures
	Is there an acceptable plan to prevent unauthorized modifications to EFB system and is there a mechanism to identify, assess and protect against security threats?
	Are there acceptable configuration control mechanisms in place?
	Has it been verified that EFB does not accept a data load that contains corrupted contents?
	Are there adequate procedural security measures implemented where technical measures are not appropriate or suitable?
9
	Use of Own-Ship Position
	Does implementation minimize the possibility of displaying misleading own-ship position to flight crews?
	Does own-ship symbol change to a non-directional depiction when heading or track not available?
	Is own-ship symbol removed when GNSS data stream no longer available?
	Has confirmation of 5 meter, airport map database accuracy been obtained?
	Is current level of zoom indicated on display?
	Have own-ship training requirements been incorporated into EFB training program?
	Has the following been added to the company’s SOP: “This EFB is not certified as a navigation system. Transport Canada has not assessed the EFB for performance or reliability of the platform hardware or software (including GPS functionality).”

Comments

Limitations or procedures required for operational use

Appendix I — Operational Aircraft Evaluation

This Appendix provides details of an operational evaluation to ensure that operations can be safely conducted using the proposed EFB procedures. This evaluation may be combined with Appendix D of this AC - Electronic Flight Bags Evaluation Process or conducted separately as circumstances warrant.

The scope of this operational evaluation may be greater than that provided below, dependent on the actual implementation. However, as a minimum the items listed below should be considered by the air operator. An associated checklist is contained in Appendix J of this AC. The operator is encouraged to create customized checklists as required.

General operation

• (1) The guiding principle of operations with an EFB is that flights should able to be conducted as safely with an EFB as with the methods or products that the EFB is intended to replace. The EFB should not add an unacceptable level of complexity for any critical activity or phase of flight. For systems with multiple EFBs, in the event of an output discrepancy there should be a means for the crew to decide which output is correct.

Workload

• (1) The implementation of EFBs should not cause a significant increase in crew workload due to positioning, using and stowing, particularly during critical flight phases. Procedures should be put in place to minimise workload and prevent crew distraction. Factors which could increase pilot workload, such as loss of an EFB, should be considered.

Installation Aspects Specific to the Operation

• (1) All aspects of the operator’s proposed EFB procedures should be evaluated in the aircraft or a simulator representative of the aircraft to ensure that any installation issues specific to the proposed operation are identified and mitigated.

Aircraft Performance Calculations

• (1) The operator should have a means to verify that the EFB outputs for aircraft performance calculations match the AFM. The EFB should have been determined during the installation evaluation to minimize the possibility of confusion and data entry errors. It should be confirmed that the operator’s flight crew members using the operator’s procedures find data entry to be easy and unambiguous. It should also be determined that the procedures allow for adequate crosscheck between crewmembers.

Electronic Navigation Charts

• (1) It should be determined that crews are able to use the electronic navigation charts as readily as paper charts. The ability to easily select charts should be evaluated and the ability of the system to accommodate short notice changes such as a change of runway should be assessed. The possibility of crew confusion resulting from chart orientation, automatic chart selection or de- cluttering should be evaluated and mitigation should be proposed for any issues arising.
• (2) Visual, instrument, and aerodrome charts (refer to ICAO Annex 4, Aeronautical Charts) should contain the information necessary, in appropriate form, to conduct the operation at a level of safety at least equivalent to the reliability provided by paper charts. The screen size and resolution must be demonstrated to display information in a comparable manner to paper aeronautical charts and the data it is intended to replace. The information should be equally readable to the paper chart it is replacing, in both light and dark conditions.
• (3) Instrument Approach Procedures (IAP). The screen must display an IAP chart in an acceptable aeronautical chart format similar to a published paper chart. The screen must be large enough to show the entire standard format, one-page IAP chart all at once, with a degree of legibility and clarity equivalent to the paper chart being replaced. This requirement is not meant to preclude panning and zooming features, but is intended to prevent a workload increase during the approach phase of flight.
• (4) Aeronautical Charts. Aeronautical navigation charts (i.e., visual flight rules (VFR) navigation charts, low- and high-altitude en route charts, and terminal procedure publications) require evaluation for operational suitability. Panning, scrolling, zooming, rotating, or other active manipulation is permissible for these Type B applications for meeting legibility requirements. An EFB display may not be capable of presenting an entire aerodrome chart (airport diagram) if the chart is the expanded detail (fold over) type. In this case, a moving map-centering feature may be desirable. Aerodrome charts must include all information useful for airport operation. Any active manipulation (e.g., zooming, panning, or decluttering) should be easily returned to the default position.

Electronic Checklists

• (1) Electronic checklist features should be evaluated to determine whether crews are able to use them as well as paper checklists. The status of checklist items should be clear to the crew and it should be easy for the crew to change the status of each item. The potential to skip checklist items or assign incorrect actions should be minimized. The complete or incomplete status of the checklist should be clear to the crew.

Appendix J — Operational Evaluation Checklist—Aircraft

Item	Operational Evaluation Checklist – Aircraft	Acceptable Yes/No/NA
1	General
	Can flights be conducted as safely with an EFB as with the methods/products it is intended to replace?
	Has it been determined that there are no noticeable conflicts between EFB and flight system interfaces, or between multiple EFBs?
	Has it been determined that In the event of an output discrepancy, there is a means for the crew to know which output is primary?
	Has it been determined that the EFB does not add an unacceptable level of complexity for any critical activity or phase of flight?
2
	Workload
	Is the workload with an EFB less than or equal to the workload for equivalent tasks without an EFB?
	Has it been determined that the EFB does not distract pilots during critical phases of flight?
	Are there policies/procedures in place to mitigate workload/distraction problems?
3
	Aircraft Performance Calculations
	Can the operator verify that aircraft performance data outputs match AFM performance data? How?
	Is the entry and manipulation of data easy and unambiguous?
	Does the system provide suitable error messages for inappropriate input/output?
	Does the system allow adequate cross-checks between crew members in practice?
4
	Electronic Navigation Charts
	Can crews use electronic charts as well as they use paper charts?
	Can the system easily accommodate short notice changes (e.g. re-clearance, change of runway)?
	Do zoom and pan features ensure that critical items are not lost from view? Do scale and orientation indications remain visible? Does the scale indication remain accurate?
	Do display or orientation options ensure that crews do not become confused about display orientation?
	Externally-sensed inputs (e.g. overlay of current aircraft position): Does the system automatically select relevant charts? Can the selection be manually overridden? Is displayed position accurate within the displayed scale?
	Does the system ensure that: critical items are not lost from view in ‘de-cluttered’ mode? there is a clear indication that the de-cluttering feature is active? printed charts are as accurate and usable as conventional paper charts?
5
	Electronic Checklists
	Can crews use electronic checklists as well as they use paper checklists? How does crew coordination of checklist actions work in practice?
	Is progress through the checklist and the status of items (complete/deferred/open) clear to the crew?
	Can the crew easily change the status of an action item?
	Can the crew remove completed actions in order to recommence the checklist from the beginning?
	Is the potential to skip checklist items or assign incorrect actions minimized?
	Can the crew easily navigate through the checklist? Are deferred actions appropriately displayed?
	Is it clear when a checklist is incomplete?
	Are ‘decision branches’ clearly displayed? Can the selection of an incorrect branch be reversed?
	Are reminders displayed for delayed actions (e.g. fuel dumping)?

Comments

Limitations or procedures required for operational use

Appendix K — Supplemental Guidance for the Development of EFB Software Applications

This Appendix provides information on best practices and general guidance for the development of commonly used EFB software applications. The specific examples used are not intended to preclude alternate methods which may accomplish similar objectives. In addition, operators who have been granted a specific approval for particular EFB software applications may wish to consider adopting the methods discussed within this attachment.

Manufacturers, operators or vendors should carefully consider their particular operational needs when developing EFB software applications in an effort to maintain the highest safety and reliability standards for their specific-use case.

The base material for this Appendix originates from the most recent revision of ICAO EFB Manual Doc. 10020; it has been modified to reflect TCCA nomenclature.

Takeoff/Landing Performance (TALP) and Weight and Balance (WW&B) Applications

• (1) Introduction
  • (a) The validity and integrity of TALP and W&B data are essential for safe flight operations. These type of EFB applications, and the operator’s procedures for their use, require thorough evaluation prior to being approved for service.
  • (b) A proper calculation workflow is of little use if data are not valid in the first place. The verification of the performance data and calculation algorithms correctness is therefore one essential step of the evaluation.
  • (c) The other part of the evaluation has to deal with the user interface and crew procedures. Experience has shown that errors involving data entry or interpretation can be frequent. A proper human-machine interface (HMI) on one side, with adequate administration and crew procedures and training on the other, are necessary to mitigate those errors.
  • (d) The application architecture, HMI, documented testing results, and the operator’s EFB procedures and training should be assessed before approving the operational use of EFB TALP and W&B applications.
• (2) Takeoff and Landing Performance Application Architecture
  • (a) TALP applications are usually separated into different layers:
    • (i) HMI (human-machine interface);
    • (ii) calculation module;
    • (iii) aircraft-specific information; and
    • (iv) airport, runway, obstacle database (AODB).

Figure K-1 shows a typical architecture of a TALP application. Individual solutions that are in use by operators might not need to be as modular as shown, but rather, have the different parts integrated into one software. Alternatively, there might be solutions where modularity is taken to a point where some or all parts are supplied by different providers.

 

 

 

Figure K-1. Typical architecture of a TALP application

• (a) Input and output HMI. The input HMI takes the pilot’s inputs (or data read from the avionics if applicable) and requests the calculation from the calculation module. The results are transferred to the output HMI.
• (b) Calculation module. The calculation module will process the data from the input HMI and determine the results, which are then sent back to the output HMI.
• (c) TALP source data generally is derived from either pre-calculated tables (e.g. runway weight limitation charts), digitized AFM or FCOM charts, or equations of motion-based software algorithms and data.
• (d) For TALP source data that is either digitized AFM data or based on equations of motion, the data is generally provided in a form that complies with the International Air Transport Association (IATA) Standard Computerized Airplane Performance (SCAP) specification. The IATA SCAP specification provides a standardized means for manufacturers, operators, and third parties to exchange airplane performance data.
• (e) A typical software system that uses the SCAP approach will consist of the calling module, a “SCAP module” (also known as a “manufacturer’s module”), and SCAP data. To obtain results, the calculation module assembles the inputs from the HMI and other sources and might call the SCAP module several times. Thus, the expression “calling module” has become widespread in the industry.
• (f) Another way for the calculation module to obtain results is to interpolate between pre calculated tables (e.g., runway weight limitation charts).
• (g) In some cases, where manufacturer software and data is not available, or when other commercial purposes exist, paper AFM or FCOM charts may be digitized by third parties that develop the data for their own commercial products.
• (h) Aircraft Performance data sources. Different sources of performance data can be used by TALP applications. Performance data can be delivered in various digitized formats:
  • (i) SCAP modules or the equivalent delivered by the manufacturer.
  • (ii) The operator can build its own digitized aircraft performance data, based on the data published in the flight manual; and
  • (iii) Data based on pre-calculated takeoff or landing performance tables.
• (i) Airport, runway, obstacle database (AODB). Takeoff and landing performance applications require information about airport, runway and obstacles. The AODB should provide this information in a suitable way. Usually, it is the part of the EFB performance applications that will be updated most often. The management of this data is critical. The operator is responsible for the data quality, accuracy and integrity of the runway and obstacle data, and should ensure this together with the data provider.

• (3) Takeoff and Landing Performance and Weight and Balance Applications HMI
  • (a) Pilot data entry errors have been a contributing factor to numerous aviation incidents and accidents. A well designed HMI can significantly reduce the risk of errors. The following design guidelines should be followed:
    • (i) input data and output data (results) should be clearly distinctive. All the information necessary for a given task should be presented together or easily accessible;
    • (ii) all data required for the performance and W&B applications should be prompted-for or displayed, including correct and unambiguous terms (names), units of measurement (e.g. kg or lbs). The units should match those from other cockpit sources for the same type of data;
    • (iii) field names and abbreviations used in the GUI should correspond to those used in the manuals and should match the labels in the cockpit;
    • (iv) if the application computes both dispatch (regulatory, factored) and other results (e.g. in flight or not factored), the flight crew should be made aware of the nature of the results;
    • (v) the application should clearly distinguish user entries from default values or entries imported from other aircraft systems;
    • (vi) the aircraft tail sign used for calculation must be clearly displayed to the flight crews, if relevant differences between tail signs exist. If tail signs are associated with different sub-fleets, the selected sub fleet should be clearly displayed to the flight crew;
    • (vii) the HMI should be designed so that input data are difficult to enter into the wrong fields of the HMI, by defining data entry rules;
    • (viii) the HMI should only accept input parameters within the aircraft’s operational envelope approved for the operator (commonly more limiting than the certified envelope). Consideration should be given to the plausibility of outputs within the AFM envelope but outside normal operating conditions;
    • (ix) all critical TALP calculation assumptions (e.g. use of thrust reversers, full or reduced thrust/power rating) should clearly be displayed. The assumptions made about any calculation should be at least as clear to pilots as similar information would be on a tabular chart;
    • (x) the HMI should indicate to the pilot if a set of entries results in an unachievable operation (for instance, a negative stopping margin);
    • (xi) the user should be able to modify its input data easily, especially to account for last-minute changes;
    • (xii) calculation results should be displayed with the input parameters used for the calculation;
    • (xiii) any active MEL/CDL/special restriction should be clearly visible and identifiable;
    • (xiv) in case of multiple runway selection, the output data should be clearly associated with the selected runway; and
    • (xv) changes of runway data by the pilot should be clearly displayed and the changes should be easy to identify.
  • (b) The development, testing and approval of a HMI are considerable investments and system integrators and operators are encouraged to evaluate the usability of an existing HMI before developing a new HMI themselves. It is also recommended to review the HMI after some time of operation in the everyday environment for unforeseeable common human errors with special regard to the specific-use case of the operator, which require changes or enhancement of the given design.
  • (c) Any new or modified HMI requires exhaustive testing of this component.
  • (d) Any major HMI modification requires a new risk assessment by the operator.

Takeoff/Landing Performance and Weight and Balance Applications Testing

• (1) Accurate TALP and W&B calculations are essential to safe aircraft operation. EFB applications can be effective tools used to make these calculations. EFB applications that use mathematical algorithms or calculation modules should be thoroughly tested before being approved for operational use.
• (2) Applications designed to perform TALP and W&B calculations must use data derived from the AFM or other appropriate sources, as deemed acceptable by TCCA.
• (3) Application testing should be conducted with the application running on a representative operating system and hardware device.
• (4) A proper evaluation of a TALP or W&B EFB application includes documented testing that verifies the calculation accuracy, user interface, and complete environmental integration. The extent of testing and supporting documentation should reflect the complexity and functionality of the application being tested.
• (5) Calculation Accuracy Tests. Tests designed to verify an application calculates TALP and W&B results that are consistent with the AFM data or advisory data provided by the aircraft manufacturer.
  • (a) The results of TALP applications are influenced by a large number of input parameters, and therefore it is not feasible to verify all possible outputs for accuracy. Test cases should be defined to sufficiently cover the entire operating envelope of the aircraft under a representative cross section of conditions for TALP applications (e.g., runway surface condition, runway slope, wind, temperature, pressure altitude, obstacle clearance, and aircraft configuration including failures with a performance impact, etc.).
  • (b) The results of W&B applications are also influenced by a large number of input parameters, and therefore it is not feasible to verify all possible outputs for accuracy. Test cases should be defined to sufficiently cover the entire operating envelope of the aircraft under a representative cross section of conditions for W&B applications (e.g., fuel load schedules, including varying fuel densities or actual fuel density if known, passenger load schedules, cargo load schedules, and unique or special cargo loads).
  • (c) Test cases should also be defined to sufficiently cover a representative cross section of an operator’s aircraft (e.g., different aircraft types, models, configurations, and modifications).
  • (d) Test cases should contain a detailed check showing that the application produces results that match or are consistently conservative to results derived from previously approved methods accepted by TCCA.
  • (e) An applicant should provide an explanation of the methods used to evaluate a sufficient number of testing points with respect to the design of their software application and databases.
  • (f) Test cases should demonstrate that the application is stable and produces consistent results each time the process is entered with identical parameters.
  • (g) Tests should be acceptable to TCCA.
• (6) User Interface Tests. Tests designed to verify that an application’s user interface is acceptable.
  • (a) Test cases should be defined to demonstrate compliance with the HMI requirements in Section 3(a).
  • (b) Test cases should be defined to demonstrate the application has a reasonable system response when incorrect values are inadvertently entered.
  • (c) Test cases should be defined to demonstrate that the application provides easily comprehended results or error messages/instructions if incorrect input values (outside envelope, wrong combination of inputs, etc.) are entered.
  • (d) Test cases should be defined that demonstrate the application does not fail or get into a state that would require special skills or procedures to bring it back to an operational state if incorrect input values are entered.
• (7) Operational Integration Tests. Tests that demonstrate application runs properly in the complete operational environment for which the EFB application is to be used.
  • (a) Test cases should be defined that demonstrate the application functions correctly on the EFB platform.
  • (b) Test cases should be defined that demonstrate the application does not adversely impact other EFB applications or aircraft systems or vice versa.
  • (c) Test cases should be defined that demonstrate the application correctly interfaces with other applications when applicable (e.g., T/O performance using results from W&B application).

Procedures, Management and Training

• (1) The evaluation of EFB applications that calculate TALP and W&B data should take into consideration all other processes, procedures, and training that support the use of the application.
  • (a) Normal Operating Procedures
    • (i) Procedures should ensure the proper use of EFB applications that calculate TALP or W&B data. The procedures should apply to the flight crew and ground personnel (Flight Dispatchers, Flight Operating Officers, Operating personnel, etc.) that may have roles defined in the use of the applications.
    • (ii) TALP and W&B data should be independently calculated and crosschecked by both pilots. When a dispatch system described in ICAO Annex 6, Part 1, Chapter 3 is used for the control and supervision of flights, the flight dispatcher (or other ground staff assigned) should verify the results are within operating limits. Any differences should be discussed before the results are used operationally. All W&B documents should be available to the dispatcher or the person on the ground responsible for the control and supervision of flight before take-off.
  • (b) Abnormal Operating Procedures
    • (i) Procedures should ensure a high level of safety can be maintained consistent with the EFB risk assessment assumptions during a loss of EFB functionality (e.g., the loss of a single application or the failure of the device hosting the application).
  • (c) Security Procedures
    • (i) The application and the data it references should be checked for integrity and protected against unauthorized manipulation, (e.g., by checking file checksum values at EFB start-up or prior to each calculation.)
  • (d) Training
    • (i) Training should emphasize the importance of executing all TALP and W&B calculations in accordance with SOP to assure fully independent and cross check calculations. As an example, one pilot should not announce the values to be entered into the HMI of the performance applications, because a wrong announcement could lead to both calculations showing the same misleading results.
    • (ii) Training should include cross-checks (e.g., with avionics or flight plan data) and gross error check methods (e.g., “rule-of-thumb”) that may be used by pilots to identify order-of-magnitude errors like entering the Zero Fuel Weight as Take Off Weight or transposed digits.
    • (iii) Training should emphasize that the use of EFBs makes TALP and W&B calculations simple and does not eliminate the necessity of good pilot performance knowledge.
    • (iv) Through the use of EFBs, new procedures may be introduced (e.g., the use of multiple flaps settings for takeoff) and pilots should be trained accordingly.
  • (e) Management of Takeoff and Landing Performance and W&B EFB Applications
    • (i) The responsibilities between the TALP and W&B management and the EFB management should be clear and well-documented. A designated person/group who is sufficiently trained should provide support for the performance tools. This person/group should have comprehensive knowledge of current regulations, TALP and W&B, and TALP and W&B software (e.g., SCAP modules) used on the EFB.

Electronic Charting Applications

• (1) Introduction
  • (a) An EFB software application that supports route planning, route monitoring and navigation by displaying required information and includes visual, instrument and aerodrome charts.
• (2) Considerations for Electronic Charting Applications
  • (a) electronic aeronautical charts should provide, at least to a minimum, a level of information and usability comparable to paper charts.
  • (b) for approach charts, the EFB software application should be able to show the entire instrument approach procedure all at once on the intended EFB hardware, with a degree of legibility and clarity equivalent to that of a paper chart.
  • (c) an EFB display may not be capable of presenting an entire chart (e.g. airport diagram, departure/arrival procedures, etc.) if the chart is the expanded detail (fold-over) type.
  • (d) panning, scrolling, zooming, rotating, or other active manipulation is permissible, and
  • (e) for data driven charts, it should be assured that shown symbols and labels remain clearly readable, (e.g. not overlapping each other). Layers of data may be used for de-cluttering.

Note: See also Annex 4 — Aeronautical Charts, Chapter 20 — Electronic Aeronautical Chart Display — ICAO.

Taxi Aid Camera System (TACS)

• (1) Description
  • (a) TACS is an EFB software application intended to increase situational awareness during taxi by displaying electronic real-time images of the actual external scene.
• (2) Consideration for TACS
  • (a) ensure real-time, live display of received imagery without noticeable time-lapse.
  • (b) adequate image quality during foreseeable environmental lighting conditions.
  • (c) display of turning or aircraft dimension aids may be provided, (e.g. turning radius, undercarriage track width, etc.). In such cases, the information provided to the pilot should be verified to be accurate.
  • (d) connection to one or more installed vision systems. Vision systems include, but are not limited to, visible light cameras, forward-looking infrared sensors and intensifying low-light level images.
  • (e) operators should establish SOPs for use of TACS. Training should emphasize use of TACS as an additional resource and not as a primary means for ground navigation or avoiding obstacles, and
  • (f) pilot use of TACS should not induce disorientation.

Airport Moving Map Display (AMMD)

• (1) Description
  • (a) This section provides some consideration on how to demonstrate the safe operational use for AMMD applications to be hosted on EFBs.
  • (b) An EFB AMMD with own-ship position symbol is designed to assist flight crews in orienting themselves on the airport surface to improve pilot positional awareness during taxi operations. The AMMD function is not to be used as the primary means of taxiing navigation. This application is limited to ground operations.
  • (c) The AMMD application is designed to indicate aeroplane position and heading (in case the own-ship position symbol is directional) on dynamic maps. The maps graphically portray runways, taxiways and other airport features to support taxi and taxi-related operations. Additionally, warning functions can be provided which notify crews about potentially dangerous conditions, i.e. inadvertently entering a RWY.
• (2) Considerations for AMMD
  • (a) an AMMD application should not be used as the primary means of taxiing navigation; primary means of taxiing navigation remains the use of normal procedures and direct visual observation out of the cockpit window.
  • (b) the total system error of the end-to-end system should be specified and characterized by either the AMMD software developer, EFB vendor or OEM, etc. The accuracy should be sufficient to ensure that the own-ship position symbol is depicted on the correct runway or taxiway.
  • (c) the AMMD should provide compensation means for the installation-dependent antenna position bias-error, i.e. along-track error associated to the GNSS antenna position to the flight deck.
  • (d) the system should automatically remove the own-ship position symbol when the aircraft is in flight (e.g. weight on wheels, speed monitoring) and when the positional uncertainty exceeds the maximum defined value.
  • (e) it is recommended that the AMMD detects, annunciates to the flight crew and fully removes depiction of own-ship data, in case of any loss or degradation of AMMD functions due to failures such as memory corruption, frozen system, latency, etc.
  • (f) the AMMD database should comply with applicable Standards for use in aviation (refer to ICAO Annex 6, Part I, 7.4 — Electronic navigation and data management); and
  • (g) the operator should review the documents and the data provided by the AMMD developer and ensure that installation requirements of the AMMD software in the specific EFB platform and aircraft are addressed.
• (3) Flight Crew Training
  • (a) The operator should define specific training in support of an AMMD’s implementation. It should be included in the operator’s overall EFB training.
  • (b) The operations manual or user guide will provide sufficient information to flight crews, including limitations and accuracy of the system and all related procedures.

Electronic Checklist (ECL)

• (1) Description
  • (a) An ECL is an EFB application which displays checklists to the flight crew by means of an EFB.
  • (b) This guidance applies to:
    • (i) ECL displaying pre-composed information or featuring a specific HMI to display the information in an optimized way to the flight crew.
    • (ii) ECL with or without capability to interact with the pilot to record the completion of the actions and checklists.
    • (iii) ECL without capability to process information from the aircraft (e.g., Stand-alone ECL), (Capability to process information from the aircraft is more critical and not addressed by this manual.); or
    • (iv) ECL displaying only normal checklists. (Non-normal/abnormal/emergency checklists and procedures are more critical and not addressed by this manual.)
  • (c) Other ECL functionalities, such as those identified in the list below, may be present in which case the TCCA is responsible for the establishment of the applicable basis for compliance.
    • (i) If the ECL receives information from the aircraft (sensed items such as aircraft system state, switch positions). The status of the sensed items may be reflected on the checklist. For example, if an action line of a checklist indicates that a button should be pressed and the aircraft sensors sense that the button has been pressed then the checklist display will indicate that the item has been accomplished.
    • (ii) If the ECL content includes non-normal (abnormal or emergency) checklists / procedures.
• (2) HMI design and Human Factors considerations
  • (a) The ECL system (hardware, software) should provide at least the same level of accessibility, usability and reliability as a paper checklist.
  • (b) HMI and Human Factor considerations:
    • (i) Accessibility time for any checklist should not be longer than an equivalent paper checklist.
    • (ii) All checklists should be easily accessible for reference or review.
    • (iii) The resulting pilot actions called from an ECL should be identical to a paper checklist.
    • (iv) It should be clearly recognizable to the pilot which items or checklists are safety relevant for the operation of the aircraft, and which are of additional nature.
    • (v) Checklists should be presented in accordance with the normal sequence of flight.
    • (vi) The title of the checklist should be displayed and distinguished at all times when in use.
    • (vii) An indication of the existence of off-screen checklist content should be provided.
    • (viii) The end of each checklist should be clearly indicated.
    • (ix) The effect of switching between ECL and other EFB applications on the same hardware should be evaluated.
  • (c) Additional HMI and Human Factor considerations for ECL with capability to interact with the pilot to record the completion of the actions and checklists:
    • (i) ECL should provide a checklist overview displaying which checklists are completed and which are not.
    • (ii) ECL should display the completion status of action items within a checklist.
    • (iii) If needed, it should be possible to restart a checklist. The crew should be able to reset the checklist with a verification step to confirm the restart.
    • (iv) If needed, it should be possible to uncheck an action item in a checklist.
• (3) Flight crew procedures
  • (a) The operator should consider the impact on pilot’s workload in determining the method of use of ECL.
  • (b) Flight crew procedures should be established to:
    • (i) Ensure that the flight crew verifies the validity of the ECL database before use.
    • (ii) Define back-up procedure in case of loss of ECL during the flight to enable access to checklists at any time (e.g., to include scenarios regarding power loss, software malfunctions, etc.).
• (4) Administration
  • (a) The operator should also establish a consistent and methodical process for modifying the ECL data and updated data transmission and implementation on the EFBs. Such processes should include a method for database applicability verification to individual aircraft in the operator's fleet.
  • (b) ECL populated data content should:
    • (i) Be concise, simple, clear and unambiguous.
    • (ii) Ensure consistency between aircraft manufacturer provided data and operator customized data (e.g. language, terminology, acronyms).
• (5) Flight Crew Training and Documentation
  • (a) The operator should define specific flight crew training in support of an ECL implementation. It should be included in the operator’s overall EFB training. The operating manual or user guide should provide sufficient information to flight crews including limitations of the system and all related procedures.

In-flight Weather (IFW)

• (1) Definition
  • (b) In-flight weather (IFW) is an EFB function enabling the crew to access meteorological information.
• (2) Intended use and limitations
  • (a) The introduction of IFW is supplemental to the information required by ICAO Annex 3 and does not supersede it. It should contribute to increased situational awareness and should support the flight crew when making strategic decisions.
  • (b) The IFW application could be used to access both information required to be on board (e.g. WAFC (World Area Forecast) data), and supplemental weather information.
  • (c) Use of IFW should be non-safety-critical and not necessary for the performance of the flight.
  • (d) In order to be non-safety-critical, IFW should not be used to support tactical decisions and/or substitute certified aircraft systems (e.g., weather radar).
  • (e) Information from the official flight documentation or aircraft primary systems should always prevail in case there is a contradiction with IFW information.
  • (f) Meteorological information in IFW applications may be displayed e.g. as an overlay over aeronautical charts, geographical maps, or, may be a stand-alone weather depiction (e.g., radar plots, satellite images, etc.).
• (3) Meteorological Information considerations
  • (a) Meteorological information can be forecasted and/or observed, and can be updated on the ground and/or in flight. It should be based on data from certified meteorological service providers or other reliable sources evaluated by the operator.
  • (b) The meteorological information provided to the flight crew should be as far as possible consistent with the one available to ground-based aviation meteorological information users (e.g., Airline Operations Center (AOC), Dispatcher, etc.), in order to establish common situation awareness and to facilitate collaborative decision-making.
• (4) Display considerations
  • (a) Meteorological information should be presented to the flight crew in a format that is appropriate to the content of the information; graphical depiction is encouraged whenever practicable.
  • Presentation should include:
    • (i) Type of information contained in the meteorological information (i.e., observed or forecasted).
    • (ii) Currency or age and validity time of the meteorological information.
    • (iii) Information necessary for interpreting the meteorological information (e.g., legend).
    • (iv) Positive and clear indication of any missing information or data in order for the flight crew to determine areas of uncertainty when making hazardous weather avoidance decisions.
  • (b) If meteorological information is overlaying on aeronautical charts, special considerations should be given to HMI issues in order to avoid adverse effects on the basic chart functions.
  • (c) Meteorological information may require reformatting for cockpit use to accommodate display size or depiction technology. However, any reformatting of meteorological information should preserve both the geo-location and intensity of meteorological conditions regardless of projection, scaling, or any other types of processing.
  • (d) IFW display should as far as possible be consistent with the flight deck design philosophy in terms of location of titles, location and visual representation of legends, element size, labeling and text styles, etc.
  • (e) It is recommended that the IFW is able to display the meteorological information in relation to the route or operational flight plan, in order to ease interpretation of forecasted information.
• (5) Training and Procedures
  • (a) The operator has to specify Standard Operating Procedures specifying the use of IFW information.
  • (b) Adequate training should be provided for the use of IFW. Training should address:
    • (i) Limitations of the IFW, in particular those presented in section (2).
    • (ii) The latency of observed weather information and the hazards associated with utilization of old information.
    • (iii) IFW information beyond ICAO Annex 3 specification is supplementary to the required information.
    • (iv) Use of the application.
    • (v) Different types of displayed information (i.e., forecasted or observed).
    • (vi) Symbology (e.g., Symbols, Colours).
    • (vii) Interpretation of meteorological information;
    • (viii) Identifying failures (e.g., incomplete uplinks, datalink failures, missing info);
    • (ix) Avoiding fixation; and
    • (x) Managing Workload.