Appendix J to TAA Advisory 2012-01

Guidance for the Development of Electronic Flight Bag Software Applications


The purpose of this appendix is to provide 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 that may accomplish similar objectives. The base material for this appendix originated in the ICAO EFB Manual Doc. 10020, revision 2. It has been customized to reflect DND/CAF nomenclature.

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.

1.       Takeoff/Landing Performance and Mass and Balance Applications

1.1.       Introduction

1.1.1       The validity and integrity of Takeoff/Landing Performance (TALP) and Mass and Balance (M&B) data are essential for safe flight operations. These types of EFB applications, and the operator’s procedures for their use, require thorough evaluation prior to being approved for service.

 1.1.2     The application architecture, human-machine interface (HMI), documented testing results, and the operator’s EFB procedures and training should be assessed before approving the operational use of EFB TALP and M&B applications.

1.2       TALP Application Architecture

1.2.1       TALP applications are usually separated into different layers:

  1. HMI;
  2. calculation module;
  3. aircraft-specific information; and
  4. airport, runway, obstacle database (AODB).

1.2.2       Figure A-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 A-1.  Typical architecture of a TALP application

Figure A-1.  Typical architecture of a Takeoff and Landing application

This figure illustrates an architecture where the pilot, or avionic box, provides an input requesting the calculation module to produce data on the take-off and landing performance for a specific airport and aircraft combination. The calculation module takes an input from the airport database, if it was not part of the input from the pilot or avionics. It will further take an input from either an air manufacturer software with aircraft-specific database, or pre-calculated aircraft-specific tables, or an aircraft-specific AFM or FCOM data. The results of the calculation form the output.


1.2.3       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.

1.2.4       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.    TALP source data is generally 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.    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.    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.    Another way for the calculation module to obtain results is to interpolate between pre‑calculated tables (e.g., runway weight limitation charts).    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.

1.2.5       Aircraft Performance data sources. Different sources of performance data can be used by TALP applications. Performance data can be delivered in various digitized formats:

  1. SCAP modules or the equivalent delivered by the manufacturer.
  2. the operator can build its own digitized aircraft performance data, based on the data published in the flight manual; and
  3. data based on pre-calculated takeoff or landing performance tables.

1.2.6       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.

1.3        Takeoff and Landing Performance and Mass and Balance Applications HMI

1.3.1        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:

  1. 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;
  2. all data required for TALP and M&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;
  3. field names and abbreviations used in the HMI should correspond to those present in the flight manuals and labels in the cockpit;
  4. 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;
  5. the application should clearly distinguish user entries from default values or entries imported from other aircraft systems;
  6. the aircraft tail sign used for calculation should 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;
  7. the HMI should be designed so that input data is difficult to enter into the wrong fields of the HMI, by defining data entry rules;
  8. 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;
  9. all critical TALP calculation assumptions (e.g., use of thrust reversers, full or reduced thrust/power rating) should be clearly displayed. The assumptions made about any calculation should be at least as clear to pilots as similar information would be on a tabular chart;
  10. the HMI should indicate to the pilot if a set of entries results in an unachievable operation (for instance, a negative stopping margin);
  11. the user should be able to modify its input data easily, especially to account for last-minute changes;
  12. when calculation results are displayed, they should be displayed together with the input parameters used for the calculation.
  13. any active MEL/CDL/special restriction should be clearly visible and identifiable;
  14. in case of multiple runway selection, the output data should be clearly associated with the selected runway; and
  15. changes of runway data by the pilot should be clearly displayed and the changes should be easy to identify.

1.4        TALP and Mass and Balance Applications Testing

1.4.1       Accurate TALP and M&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.

1.4.2       Applications designed to perform TALP and M&B calculations must use data derived from the AFM or other appropriate sources, as deemed acceptable by the TAA.

1.4.3       Application testing should be conducted with the application running on a representative operating system and hardware device.

1.4.4       A proper evaluation of a TALP or M&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.

1.4.5       Calculation Accuracy Tests. Tests designed to verify an application calculates TALP and M&B results that are consistent with the AFM data or advisory data provided by the aircraft manufacturer.    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.).    The results of M&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 M&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).    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, etc.).    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 the OAA.    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.    Test cases should demonstrate the application is stable and produces consistent results each time the process is entered with identical parameters.    Tests should be acceptable to the OAA.

1.4.6       User Interface Tests. Tests designed to verify that an application’s user interface is acceptable.    Test cases should be defined to demonstrate compliance with the HMI requirements in Section 1.3.1.    Test cases should be defined to demonstrate the application has a reasonable system response when incorrect values are inadvertently entered.    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.    Test cases should be defined to demonstrate that 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.

1.4.7       Operational Integration Tests. Tests that demonstrate that the application runs properly in the complete operational environment for which the EFB application is to be used.    Test cases should be defined to demonstrate the application functions correctly on the EFB platform.    Test cases should be defined to demonstrate the application does not adversely impact other EFB applications or aircraft systems, or vice versa.    Test cases should be defined to demonstrate the application correctly interfaces with other applications, when applicable (e.g.T/O performance using results from W&B application).

1.5        Procedures, Management and Training.

The evaluation of EFB applications that calculate TALP and M&B data should take into consideration all other processes, procedures and training that support the use of the application.

1.5.1       Normal Operating Procedures    Procedures should ensure the proper use of EFB applications that calculate TALP or M&B data. The procedures should apply to the flight crew and ground personnel (Flight Dispatchers, Flight Operating Officers, Operating personnel, etc.) who may have roles defined in the use of the applications.    TALP and M&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 M&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.

1.5.2       Abnormal Operating Procedures    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).

1.5.3       Security Procedures    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.)

1.5.4       Training    Training should emphasize the importance of executing all TALP and M&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.    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 Mass as Takeoff Mass or transposed digits.    Training should emphasize that the use of EFBs makes TALP and M&B calculations simple and does not eliminate the necessity of good pilot performance knowledge.    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.

1.5.5       Management of Takeoff and Landing Performance and M&B EFB applications    The responsibilities between the TALP and M&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 M&B, and TALP and M&B software (e.g., SCAP modules) used on the EFB.

2.        Electronic Charting application

2.1        Description

2.1.1       An EFB software application that supports route planning, route monitoring and navigation by displaying required information and includes visual, instrument and aerodrome charts.

2.2        Considerations for Electronic Charting applications

  1. electronic aeronautical charts should provide, at least to a minimum, a level of information and usability comparable to paper charts;
  2. 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;
  3. 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;
  4. panning, scrolling, zooming, rotating, or other active manipulation is permissible; and
  5. 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.


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

3.        Taxi Aid Camera System (TACS)

3.1        Description

3.1.1       TACS is an EFB software application used to increase situational awareness during taxi by displaying electronic real-time images of the actual external scene.

3.2        Considerations for TACS

  1. ensure real-time, live display of received imagery without noticeable time-lapse;
  2. adequate image quality during foreseeable environmental lighting conditions;
  3. 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;
  4. 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;
  5. 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
  6. pilot use of TACS should not induce disorientation.

4.        Airport Moving Map Display (AMMD)

4.1        Description

4.1.1       This section provides some considerations on how to demonstrate the safe operational use for AMMD applications to be hosted on EFBs.

4.1.2       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 only.

4.1.3       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, e.g., inadvertently entering a RWY.

4.2        Considerations for AMMD

  1. 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;
  2. 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;
  3. 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;
  4. 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;
  5. 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.;
  6. 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
  7. 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.

4.3        Flight crew training

4.3.1       The operator should define specific training in support of an AMMD’s implementation. It should be included in the operator’s overall EFB training.

4.3.2       The operations manual or user guide will provide sufficient information to flight crews, including limitations and accuracy of the system and all related procedures.

5.        Electronic Checklist application

5.1        Description

5.1.1       An Electronic Checklist (ECL) is an EFB application which displays checklists to the flight crew by means of an EFB.

5.1.2       This guidance applies to:

  1. ECL displaying pre-composed information or featuring a specific HMI to display the information in an optimized way to the flight crew;
  2. ECL with or without capability to interact with the pilot to record the completion of the actions and checklists;
  3. 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 advisory.); or
  4. ECL displaying only normal checklists. (Non-normal/abnormal/emergency checklists and procedures are more critical and not addressed by this advisory.)

5.1.3       Other ECL functionalities, such as those identified in the list below, may be present in which case the TAA (DTAES staff) is responsible for the establishment of the applicable basis for compliance.

  1. 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.
  2. If the ECL content includes non-normal (abnormal or emergency) checklists/procedures.

5.2        HMI design and Human Factors considerations

5.2.1       The ECL system (hardware, software) should provide at least the same level of accessibility, usability and reliability as a paper checklist.

5.2.2       HMI and Human Factor considerations:

  1. Accessibility time for any checklist should not be longer than an equivalent paper checklist;
  2. All checklists should be easily accessible for reference or review;
  3. The resulting pilot actions called from an ECL should be identical to a paper checklist;
  4. 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;
  5. Checklists should be presented in accordance with the normal sequence of flight;
  6. The title of the checklist should be displayed and distinguished at all times when in use;
  7. An indication of the existence of off-screen checklist content should be provided;
  8. The end of each checklist should be clearly indicated;
  9. The effect of switching between ECL and other EFB applications on the same hardware should be evaluated.

5.2.3       Additional HMI and Human Factor considerations for ECL with capability to interact with the pilot to record the completion of the actions and checklists:

  1. ECL should provide a checklist overview displaying which checklists are completed and which are not;
  2. ECL should display the completion status of action items within a checklist;
  3. 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;
  4. If needed, it should be possible to uncheck an action item in a checklist.

5.4        Flight crew procedures

5.4.1       The operator should consider the impact on pilot’s workload in determining the method of use of ECL.

5.4.2       Flight crew procedures should be established to:

  1. Ensure that the flight crew verifies the validity of the ECL database before use;
  2. 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.).

5.5        Administration

5.5.1       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.

5.5.2       ECL populated data content should:

  1. be concise, simple, clear and unambiguous; and
  2. ensure consistency between aircraft manufacturer-provided data and operator-customized data (e.g., language, terminology, acronyms).

5.6        Flight Crew Training and Documentation

5.6.1       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.

6.0      In-flight Weather (IFW) application

6.1.       Definition

6.1.1       In the context of this advisory, in-flight weather (IFW) is an EFB function enabling the crew to access meteorological information.

6.2.       Intended use and limitations

6.2.1       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.

6.2.2       The IFW application could be used to access both information required to be on board (e.g., World Area Forecast (WAFC) data), and supplemental weather information.

6.2.3       Use of IFW should be non-safety-critical and not necessary for the performance of the flight.

6.2.4       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).

6.2.5       Information from the official flight documentation or aircraft primary systems should always prevail in case there is a contradiction with IFW information.

6.2.6       Meteorological information in IFW applications may be displayed as an overlay over aeronautical charts or geographical maps, or it may be a stand-alone weather depiction (e.g., radar plots, satellite images, etc.).

6.3.       Meteorological Information considerations

6.3.1       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.

6.3.2       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.

6.4.       Display considerations

6.4.1       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.

6.4.2       The presentation should include:

  1. Type of information contained in the meteorological information (i.e., observed or forecasted);
  2. Currency or age and validity time of the meteorological information;
  3. Information necessary for interpreting the meteorological information (e.g., legend);
  4. 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.

6.4.3       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.

6.4.4       Meteorological information may require reformatting for cockpit use to, for example, 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.

6.4.5       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.

6.4.6       It is recommended that the IFW be able to display the meteorological information in relation to the route or operational flight plan for ease of interpretation of forecasted information.

6.5.       Training and Procedures

6.5.1       The operator has to specify Standard Operating Procedures specifying the use of IFW information.

6.5.2       Adequate training should be provided for the use of IFW. Training should address:

  1. Limitations of the IFW, in particular those presented in section 6.2.;
  2. The latency of observed weather information and the hazards associated with utilization of old information;
  3. IFW information beyond Annex 3 specification and which are supplementary to the required information;
  4. Use of the application;
  5. Different types of displayed information (i.e., forecasted or observed);
  6. Symbology (e.g., Symbols, Colors);
  7. Interpretation of meteorological information;
  8. Identification of failures (e.g., incomplete uplinks, datalink failures, missing info);
  9. Fixation avoidance; and
  10. Workload management.

Top of page

Back to TAA Advisory 2012-01