11.6 Active Regions. Active regions are regions to which special user commands apply. The active region can be text, a graphic image, a window, a frame, or another document object. If the display uses active regions, these regions should be clearly indicated.
11.7 Managing Multiple Open Applications and Documents. The EFB application should provide continuous indication of which application and/or document is active if the system supports multiple open documents, or if the system allows multiple open applications. The active application/document is the one currently displayed and responding to user actions. Under nonemergency, 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 open applications are running and switch to any one of these open applications easily. The user should also be able to open a new application quickly and easily. When the user returns to an application running in the background, it should appear in the same state as when the user left the application, other than differences associated with the progress or completion of processing performed in the background.
11.8 Controls. All controls required for the operation of the EFB in flight should be within reach and view of the appropriate flightcrew member from their normally seated position on the flight deck. The EFB should not visually obstruct other controls and instruments.
In choosing and designing input devices, such as keyboards, touch screens, or cursor-control devices, operators should consider the type of entry to be made and flight deck environmental factors, such as turbulence and other normal vibrations affecting the usability of the input device. For touch screens, pilots may need physical locations or structures (e.g., armrests) to stabilize their arm, hand, and fingers in order to make accurate inputs. Ensure touch screens do not result in unacceptable levels of pilot workload and error rates. The performance parameters of cursor-control devices are typically tailored for the application requirements as well as for the flight deck environment. Input devices should provide feedback to indicate when they are operational. Since touch screens provide little or no tactile feedback or control motion, visual and/or aural or other touch activation feedback is especially important. Other touch screen considerations include selecting the touch technology (e.g., resistive or capacitive), controlling screen contaminates which may reduce readability (e.g., skin oils or perspiration), and mitigating inadvertent operation. For further guidance on EFB controls, refer to AC 20-175, Controls for Flight Deck Systems.
11.9 System Error Messages. If an application is fully or partially disabled, or is not visible or accessible to the user, it may be desirable to have a positive indication of its status to the user upon request. Messages should be operationally relevant and limited to minimize the adverse effects on crewmember workload. EFB status and fault messages should be prioritized, and the message prioritization scheme evaluated and documented. When displaying messages, and there are additional messages in the queue not currently displayed, there should be an indication of additional messages.
11.10 Data Entry Screening and Error Messages. If user-entered data is not of the correct format or type needed by the application, the EFB should not accept the data. The EFB should provide an error message clearly communicating to the crewmember which entry
14 is suspect and specifying what type of data it expects. The EFB and application software should incorporate input error checking to detect input errors at the earliest possible point during entry, rather than on completion of a possibly lengthy invalid entry.
11.11 Error and Failure Modes.
11.11.1 Crewmember Error. The system should be designed to minimize the occurrence and effects of crewmember error and enable the crewmember to detect and manage errors when they occur. For example, terms for specific types of data or the format for entry of latitude/longitude 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. The possible effects of undetected errors in each EFB application should be evaluated. The evaluation should address the adequacy of the user interface, accessibility of controls, ability to view controls, annunciations, displays and printers, and the effect on flightcrew workload and head-down time. The evaluation should also consider the effects of crewmember (procedural) errors determined by feedback from crewmembers.
11.11.2 I dentifying Failure Modes . The EFB should be capable of alerting the crewmember of probable EFB application/system failures.
11.12 Crewmember Workload. The EFB software design should minimize crewmember workload and flightcrew head-down and/or eyes-in time. The positioning (e.g., location and viewing angle), use, and stowage of the EFB should not result in unacceptable crewmember workload. Avoid complex, multi-step data entry tasks during taxi, takeoff, descent, approach, landing, and non-cruise phases of flight. An evaluation of EFB applications should include a qualitative assessment of incremental pilot workload, related to the use of the EFB applications in isolation, as well as the use of those applications concurrent with other aircraft system interfaces and their safety implications.
If EFB functionality includes use during taxi, takeoff, descent, approach, landing, non-cruise phases of flight, or abnormal and emergency operations, its use should be evaluated during simulated or actual aircraft operations under those conditions.
11.13 Electronic Display of Aeronautical Charts.
11.13.1 Similarity to Paper. Electronic aeronautical charts should provide a level of information comparable to paper charts.
11.13.2 L egibility . Visual, instrument, and aerodrome charts (refer to International Civil Aviation Organization (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. As Type B applications, the screen size and resolution should 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.
11.13.3 S creen Size Considerations. As Type B applications, the screen should be large enough to show the instrument approach procedure (IAP) chart 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. Alternate representations of IAP charts will need to be evaluated for operational suitability by the Aircraft Evaluation Division for functionality and HFs.
11.13.4 Aeronautical Charts. Aeronautical navigation charts (e.g., 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 might 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. As Type B applications, aerodrome charts should include all information useful for airport operation.
Any active manipulation (e.g., zooming, panning, or decluttering) should be easily returned to the default position.
11.14 F light Standardization Board Reports (FSBR) /Operational Suitability Reports (OSR). FSBRs/OSRs addressing the use of various EFB applications may be available.
11.15 Applications Supported by Data Link.
11.15.1 M eteorological Information (MET)/Aeronautical Information Service (AIS) Products .
Data link-supported EFB applications may display approved sources of weather for strategic/flight planning purposes. Weather and aeronautical information, such as data-linked MET and AIS products, are for advisory use only. These products are intended to enhance situational awareness, but lack the service delivery reliability and updating necessary for tactical maneuvering/use. Data-linked MET and AIS products are not intended for making tactical in-flight decisions regarding flight safety when avoiding adverse weather, airspace, or obstacle hazards (e.g., negotiating a path through a weather hazard area). Instead, current data-linked MET and AIS products support strategic decision making (e.g., route selection to avoid a weather hazard area in its entirety) and flight planning. For further guidance on the use of MET and AIS products, refer to AC 00-63, Use of Flight Deck Displays of Digital Weather and Aeronautical Information.
11.15.2 Graphical Weather Information. Data link graphical weather from sources such as XM radio and Next Generation Weather Radar (NEXRAD) may be from approved sources of advisory weather information and are only intended to be used for strategic/flight planning purposes. Data link graphical weather information is not intended to be used for tactical decisions because data quality is uncontrolled for aviation use. Data link graphical weather data is not intended to be used as a substitute for airborne weather radar or thunderstorm detection equipment. To qualify as a Type B application, graphical weather information should include a clear indication to the crew about the age of the information.
11.16 Database Accuracy and Quality. Database errors can have a significantly greater impact on the crewmember than other elements of the EFB. With this in mind, the EFB should have a database with appropriate quality control (QC) systems, and should be based on accuracy standards to avoid the potential presentation of hazardously misleading information. When developing the database and data quality requirements, we recommend the use of RTCA DO-200, Standards for Processing Aeronautical Data. A means to identify the database version, effective date, and valid operating period should be provided. For Type B applications displaying EFB own-ship position intended for airport surface operations, the airport map database should have an accuracy of 5 meters or less. However, if more accurate data is not available, the database accuracy should not exceed 30 meters. Combined with a maximum position source error, which is equivalent to an installed GNSS source, the total error budget for position source is 50 meters. The 50-meter accuracy value is approximately half of the separation of taxiways at aerodrome code letter E, as specified in ICAO Annex 14, Aerodromes. A statement of the QC processes applied and database accuracy by the database manufacturer should suffice for determination of database error contribution to the total error budget.
11.17 Display of EFB Own-Ship Position. EFB own-ship position on an EFB should only be displayed when the installed flight display, weather display, traffic display, or map display also depict own-ship position. For installed EFB displays, refer to AC 20-173 for additional guidance.
11.17.1 Proper Use of EFB Own-Ship. Operators should ensure flightcrew members understand the proper use of EFB own-ship position, including the need for concurrent use with certified avionics own-ship depiction. Operators should also ensure that flightcrew members understand the means of differentiation in order to distinguish between information provided by the certified avionics system and information provided by the supplemental or “secondary” EFB system. The flightcrew’s reference for maneuvering the aircraft in the air is the certified primary flight and navigational displays. Therefore, flightcrew members should be able to resolve own-ship conflicts between the EFB information depicted by the “secondary” system and the primary, certified avionics system during in-flight use. For EFB own-ship position use in ground operations, the use of external visual references (e.g., airport signs and markings) is sufficient for maneuvering the aircraft.
11.17.2 E FB Own -Ship Display Supporting Recommendations.
11.17.2.1 Position Source Selection. Use position data from an installed GNSS source.
Portable equipment is more likely to experience signal blockage, signal degradation, and performance degradation. Position data from a portable GNSS source may be acceptable, but for consistency of availability, we recommend the operator select an external GNSS source rather than the GNSS internal to the portable EFB.
11.17.2.2 EFB Own-Ship Directionality. Change own-ship to a nondirectional (circular) depiction when track or heading is not available.
11.17.2.3 EFB Own-Ship GNSS Data Stream. Remove EFB own-ship if the position becomes unavailable or is insufficient for the application. This will guard against a “frozen” own-ship condition caused by position source signal or power loss and removal should take no more than 3 seconds.
11.17.2.4 EFB Own-Ship Surface Use Accuracy. For airport map applications, choose a database with an accuracy of 5 meters or less. For airports where such data is not currently available, a database accuracy of up to 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.
Note 2: To qualify as a Type B EFB application, the use of own-ship position on the airport surface display is based on compliance with the operational guidelines in AC 120-74, Parts 91, 121, 125, and 135 Flightcrew Procedures During Taxi Operations.
11.17.2.5 M ap Zoom. Design the application to indicate the current level of zoom or scale of the display. The design should ensure the zoom level is compatible with the position accuracy of the own-ship symbol.
11.18 Performance/Weight and Balance (W&B) Applications.
11.18.1 W& B. Type B applications for W&B are based on the existing information found in the FAA-approved Airplane Flight Manual (AFM), pilot’s operating handbook (POH), or W&B manual for an aircraft. Type B W&B applications use data management software to provide data reference and mathematical calculations to simplify determination of aircraft W&B. To qualify as a Type B application, W&B applications should adhere to existing approved data and be validated for accuracy in the entire aircraft-operating envelope. Type B W&B applications may use algorithms to calculate W&B results or use basic mathematics combined with data spreadsheets to determine W&B results.
Algorithms may have the ability to interpolate within approved data, but should not extrapolate, and therefore should be tested and proven accurate by the manufacturer or operator to represent the approved data. Type B W&B applications are produced for a specific aircraft and based on FAA-approved AFM data.
11.18.2 Performance Applications. Type B applications for performance are based on existing published data found in the FAA-approved AFM, POH, or performance manual for an aircraft. Type B performance applications use data management software to provide data reference and mathematical calculations to simplify the determination of applicable aircraft performance data. To qualify as a Type B application, performance applications should adhere to this published data and be validated for accurate determination of aircraft performance for the entire operating envelope. Type B aircraft performance
18 applications may use algorithms to calculate results or use basic mathematics combined with data spreadsheets to determine results. Algorithms may have the ability to interpolate within approved data, but should not extrapolate beyond the information contained in the current published data. These algorithms should be tested and verified to meet existing FAA-approved AFM performance data. Type B performance applications should not extrapolate or project results not represented by the FAA-approved AFM data point’s envelope of conditions including, but not limited to, pressure, altitude, temperature, and weight. Type B aircraft performance applications are produced for a specific aircraft type based on FAA-approved AFM data.
11.18.3 Testing Performance and W&B Applications. To qualify as a Type B application, W&B and/or performance applications require demonstration testing prior to EFB operational use. Applications using data spreadsheets where each data point is entered into software data and then referenced for output should be verified for accurate data selection.
Applications based on algorithms calculating their output should be verified to accurately represent the AFM data they replace. Creation of a new algorithmic method to replace AFM data is not allowed in Type B applications. Type B algorithms should adhere to the same data methodology as the FAA-approved AFM data. The Type B application should always be demonstrated to be traceable to the FAA-approved AFM data. These Type B applications should not perform calculations or provide output when the user makes an entry input which is outside the AFM data envelope(s). Sufficient data points based on application architecture should be tested and documented to show the applications accurately adhere to and are limited to the FAA-approved AFM data envelope segments and, for performance, should represent net climb gradients with considerations including, but not limited to, level-off, acceleration, transitions, and engine takeoff power time limits. Type B applications for performance should accurately address engine inoperative gradients and obstacle clearance plane and/or weight limits. Transition from airport area performance to en route climb performance and obstacle clearance should be addressed.
Type B applications are suitable only insofar as they accurately reproduce the AFM data.
12 EFB PROGRAM COMPONENTS. A part 91K, 121, 125, or 135 operator seeking authorization to use EFB applications on either portable or installed equipment should obtain OpSpec/MSpec/LOA A061, Electronic Flight Bag (EFB) Program. EFB program specifics (e.g., operating procedures, maintenance procedures, administrative procedures, and training modules) should be developed, as applicable, and be available to the FAA.
FAA authorization for an EFB program will be granted upon successful evaluation of an applicant’s program operation.
12.1 Paper Removal. If an operator has an EFB program authorized with adequate mitigations or develops adequate mitigations as a modification to an existing program, it is possible to remove some or all paper products from the aircraft using an equivalent level of safety (ELOS). An operator proposing to remove paper from the aircraft should have program mitigations in place to prevent an EFB failure resulting in the loss of any aeronautical information required for the operation of the flight. Although this AC categorizes EFB applications into Types A and B, required aeronautical information is defined by regulation and legal interpretations outside the scope of this AC. This requirement applies to paper removal for any crewmember, not only the pilot or copilot.
19 Note: Electronic checklists (ECL), including normal, abnormal, and emergency, may be presented as an EFB function; however, a current paper backup checklist may be required by an aircraft equipment manufacturer to be carried on board the aircraft and be readily accessible to the crew.
12.2 Operational Procedures.
12.2.1 O perational Procedures for EFB Hardware and EFB Applications. EFB programs should contain operational procedures for the use of EFB hardware and EFB applications in the aircraft. These procedures should define the roles of the flightcrew, cabin crew, and dispatch/flight following, including but not limited to:
• P rocedures defining expectations of how the crewmember should use each EFB application during ground operations and under all flight conditions.
• Procedures defining how the crewmember will report irregularities of EFB hardware or EFB applications and how the operator will modify those existing policies and procedures based on crewmember feedback.
• Procedures for normal, abnormal, and emergency use by crewmembers.
• Procedures for notifying crewmembers and dispatch/flight following of any changes to the EFB program.
Note 1: Normal procedures should address an EFB’s preflight and/or flight planning use, in-flight use/stowage/power assurance, and shutdown procedures.
Note 2: Normal procedures should include preflight inspection of a portable and/or battery-powered EFB’s physical condition, including bulging, dents, cracks, or other damage that may indicate a potential EFB failure or, if applicable, a potential lithium-type battery fire.
12.2.2 P rocedures and Training for Using EFBs with Other Flight Deck Systems . Procedures and training should address the actions to take when information provided by an EFB does not agree with other flight deck sources or when one EFB disagrees with another.
Procedures and training should address applicable aircraft type design considerations when an EFB is simultaneously displaying information with existing avionics displays and procedures should identify which information source will be primary and which source will be secondary. Ultimately, procedures and training should ensure the flightcrew member understands which system to use for a given purpose, especially when installed avionics and EFBs (either portable or installed) are providing similar information.
12.2.3 Crewmember Awareness of EFB Software/Database Revisions. T he operator should have a procedure in place to allow crewmembers to confirm the revision numbers and/or dates of EFB flight databases and software installed on their units for each flight. An example of a date sensitive revision is an aeronautical chart database on a 28-day revision cycle.
Procedures should specify what action to take if the applications or databases loaded on an EFB are out of date.
20 Note: Databases not adversely affecting aircraft operations, such as maintenance log forms, a list of airport codes, or a captain’s atlas, do not require the confirmation of revision dates by crewmembers.
12.2.4 Procedures to Mitigate and/or Control Workload. Procedures should mitigate and/or control additional workloads created by using an EFB.
12.2.5 Defining Responsibilities for Performance/W& B Calculations. The operator should develop procedures defining any new roles the flightcrew member and dispatch may have in creating, reviewing, and using performance/W&B calculations supported by EFBs.
12.3 Administrative Procedures.
12.3.1 EFB Program Modifications. An EFB program should have processes in place to identify and evaluate minor hardware and software modifications in accordance with the guidelines described in this AC. Minor program changes include:
• Adding/updating Type A EFB applications.
• Updating Type B EFB applications.
• Incorporating Operating System (OS) updates.
Note 1: EMC testing may need to be performed depending on the portable EFB EMC demonstration method utilized.
Note 2: Type B EFB application updates and EFB OS updates may warrant significant changes to crewmember training, procedures, and use. If any doubt exists about whether or not a program modification is considered minor or significant, the operator should consider it significant unless they determine, through contact with the FAA principal inspector (PI) and/or cabin safety inspector (CSI), that it is minor.
12.3.2 EFB Program Catalog. The EFB program catalog is a reference of the EFB hardware (make and model) and EFB applications used by crewmembers on each aircraft M/M/S and maintains configuration management of EFB program elements. An EFB program should have a process defined to keep the catalog current and readily available for PIs and CSIs. A record should be maintained for any change to the EFB program catalog; this record should be retained by the operator for 3 months. The catalog should also include:
• Current EFB OS, to include current version.
• EFB applications, to include current version.
Note: Multiple EFB applications may be bundled or integrated. Regardless, the program catalog identifies and tracks both the bundled grouping and those applications listed in Appendices A and B supporting the bundled group.
12.3.3 Software Revision. It is the responsibility of the operator to ensure the OS and EFB applications perform as intended. Other applications (i.e., non-EFB applications) hosted on a portable EFB should not adversely affect the EFB applications. To continue to qualify as Type A or B applications, unauthorized modification of, or the loading of, any new or additional software intended for operational use is not permitted unless the software can be demonstrated to perform as originally intended. Application software, OS program changes, and system configuration settings should be controlled and tested prior to use in flight. In addition to the operator’s responsibilities described above, it is the responsibility of the pilot in command (PIC) to verify that any EFB depiction of an en route, terminal area, approach, airport map, or sectional is current and up-to-date. One means is to ensure each PIC becomes familiar with all available information concerning the flight, to include receipt of appropriate Notices to Air Missions (NOTAM) prior to departure and prior to arrival.
12.3.4 D atabase Update Process.
12.3.4.1 Databases. The operator should establish a method for revising EFB databases and establishing system verification with each update. The method of data revision should ensure the integrity of the data the operator loads and not negatively affect the integrity of the EFB operation. Especially when using internet and/or wireless means, procedures should exist to protect the EFB data from corruption and/or IUEI. Database revisions do not include application software or OS changes. Operators should not perform database and/or application software changes during operations (e.g., taxi, takeoff, in-flight, and landing). MET and AIS data link services, as described in AC 00-63, may receive updates for overlay information during operations
(e.g., graphical weather).
12.3.4.2 Revision Control. Operators should also establish revision control procedures so crewmembers and others can ensure the contents of the database are current and complete. These revision control procedures may be similar to the revision control procedures used for paper or other storage media. For data subject to a revision cycle control process, it should be readily evident to the user which revision cycle is currently loaded into the EFB.
12.3.5 Data Storage and Retrieval Considerations.
12.3.5.1 Archive Data. If archiving data is required, operators should establish procedures to archive or retain old data. For archived data, the length of time data is kept depends on the kind of information being archived. Some information, such as maintenance historical data, may be required to be kept for the life of the aircraft. The information (data) archived should be retrievable for the data retention period. This may include a need to convert data from older formats to ensure it is accessible by currently used tools.
Operators should download maintenance discrepancy logs into a permanent record at least weekly.
12.3.5.2 Retrieval Considerations. The EFB should permit any authorized representative of the Administrator or the National Transportation Safety Board (NTSB) to retrieve, view, or print the information contained in any EFB upon receipt of a reasonable request. If the FAA or NTSB requires an operator to provide information, the operator should provide the data in a format a requesting agency can use.
12.4 Maintenance Procedures. EFB programs should include processes to ensure all EFB hardware (e.g., viewable stowage, batteries, and displays) is properly maintained for its planned life cycle.
12.5 Security Procedures.
12.5.1 Malicious Intent. The operator is responsible for ensuring security controls are in place to mitigate against the risk of IUEI to an EFB’s OS architecture, its specific hosted applications, and any of the databases or data links used to enable its hosted applications
(i.e., security risk assessment; refer to National Institute of Standards and Technology (NIST) Special Publication 800-53, Security and Privacy Controls for Information Systems and Organizations, as one example). The operator is also responsible for protecting the EFB from possible contamination from malware. Evidence should be provided, through analysis, testing, or a combination of both, to ensure EFB security is effective. The operator should define the processes and procedures to maintain the security level of the EFB during its entire operational life cycle.
12.5.2 L evel of EFB Security . The appropriate level of EFB security depends on the criticality of the usage of the EFB application (e.g., an EFB which only holds a list of fuel prices may require less security than an EFB used for performance calculations). Beyond the level of security to ensure the EFB can properly perform as intended, the appropriate level of security ultimately depends on the capabilities of the EFB, including connections to other systems. Security impacts of connections to aircraft systems should be addressed, and special conditions may need to be addressed (refer to AC 20-173 for additional guidance).
12.5.3 S ecurity Considerations . The following nonexhaustive list contains some examples of safety and security defense layers an operator should consider:
1. Individual system firewalls.
2. Clustering of systems with similar safety standards into domains.
3. Data encryption and authentication.
4. Virus scans.
5. Keeping the OS up-to-date.
6. Initiating air/ground connections only when required and always from the aircraft.
7. “Whitelists” for allowed internet domains.
8. “Whitelists” for allowed applications.
9. Virtual private networks (VPN).
10. Granting of access rights on a need-to-have basis.
11. Prohibiting “rooting” or “jailbreaking” of devices by employees.
12. Troubleshooting procedures should consider security threats as a potential root cause of EFB misbehavior, and responses should be developed to prevent future successful attacks, when relevant.
13. Virtualization.
14. Forensic tools and procedures.
15. Remote management applications.
16. Periodically inspecting devices for compliance with the company’s EFB program.
17. Requiring passcodes for device access.
12.6 Operator Training. An EFB program should incorporate a means to train crewmembers when EFBs are introduced into an operation and when any changes to EFB hardware or EFB applications are made. EFB training should be integrated and incorporated into existing training modules during initial, transition, and recurrent training, when appropriate. Training should emphasize, but is not limited to, the following subjects and any other areas emphasized in this AC:
• The operation and controls of applicable EFB hardware, to include components and peripherals.
• The operation of the available applications and their use in the operation of the aircraft.
• The awareness of new EFB program procedures.
• The differences between a PED and an EFB.
• Limitations of EFB information, to include the relationship between the use of an EFB with traditional installed avionics and conditions (including phases of flight) when information on the EFB should be tempered or terminated.
• A description of EFB failures and applicable operational procedures, to include procedures for obtaining a backup.
• A description of security concerns and security procedures, such as operational or security procedures.
• Crew Resource Management (CRM) training in EFB procedures and use, preflight checks of the system, the use of each application on the EFB (to include display and application management), and procedures for cross-checking data entry and computed information.
12.6.1 Training of Non-Flightcrew Members. EFB training may be required for non-flightcrew members if they are using similar devices and applications and are interacting with flightcrew members using the same devices and applications. Examples are maintenance
24 personnel, loading personnel, and dispatchers. Training should emphasize the coordinated procedures with flightcrew members.
12.6.2 T raining Considerations for Installed Equipment. For EFB applications displayed on installed equipment, there may be additional training required. Additional conditions, limitations, and procedures defined in an AFM, Airplane Flight Manual Supplement (AFMS), Rotorcraft Flight Manual (RFM), Rotorcraft Flight Manual Supplement (RFMS), FSBR, OSR, or another form of documentation may be required to be included in an operator’s training program. The following nonexhaustive list contains some examples of this additional documentation, which should be addressed in training:
• D escriptions of authorized special flight maneuvers, operations, and procedures the operator conducts when using an EFB.
• Differentiation between EFB-derived information and certified avionics information.
• Any special pilot/controller procedures when using EFB-based information.
• Geographical areas authorized for specific EFB operations, if applicable.
• Authorized methods to defer inoperative EFB equipment.
12.6.3 P ractical Training . Training should provide an opportunity for instruction, demonstration, and practice using the actual or simulated EFB equipment and displays. Flight simulation training devices (FSTD) and other approved training devices (e.g., procedures trainers) may be used as a tool to train crewmembers on the use of EFBs. If an EFB program is authorized, EFB use and performance in the full flight simulator (FFS) should represent actual flight operations.
12.7 M inimum Equipment Lists (MEL).
12.7.1 Po rtable EFBs . The Master Minimum Equipment List (MMEL) and MEL are not applicable to portable EFB hardware, or EFB applications.
Note: W hile not covered by an operator’s MEL, the loss of certain Type B EFB applications affecting operational regulatory requirements should be addressed in company procedures and establish mitigation means.
12.7.2 In stalled EFBs . Installed hardware is subject to MMEL/MEL requirements.
12.8 Safety Management System (SMS). Part 121 operators should, under 14 CFR part 5, implement a formal process, using the SMS, for gathering feedback on the EFB program, to include any irregularities, malfunctions, or lessons learned. Use this process during design, installation, modifications, or improvements to procedures and/or training.
Parts 91K and 135 operators are recommended to implement a similar process under the Safety Management System Voluntary Program (SMSVP) described in FAA Order 8900.1, Volume 17, Safety Management System.