13 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.
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 flightcrew member 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 flightcrew member which entry is suspect and specifies 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 Flightcrew Member Error. Design the system to minimize the occurrence and effects of flightcrew member error and enable the flightcrew member 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 flight deck crewmember workload and head-down time. The evaluation should also consider the effects of flightcrew member (procedural) errors determined by feedback from flightcrew members.
11.11.2 Identifying Failure Modes. The EFB should be capable of alerting the flightcrew member of probable EFB application/system failures.
11.12 Flightcrew Member Workload. The EFB software design should minimize flightcrew member workload and head-down time. The positioning (e.g., location and viewing angle), use, and stowage of the EFB should not result in unacceptable flightcrew member 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,
14 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 Legibility. 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.
11.13.3 Screen Size Considerations. The screen must be capable of displaying an instrument approach procedure (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. Alternate representations of IAP charts will need to be evaluated for operational suitability by the Aircraft Evaluation Division (AFS-100) for functionality and HFs.
11.13.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 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. 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.
11.14 Flight Standardization Board (FSB) Reports/Operational Suitability Reports (OSR). FSB Reports/OSRs addressing the use of variable EFB applications may be available.
11.15 Applications Supported by Data Link.
11.15.1 Meteorological 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. Do not use data-linked MET and AIS
15 products 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-45, Aviation Weather Services, and 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 can only be used for strategic/flight planning purposes. Do not use data link graphical weather information for tactical decisions because data quality is uncontrolled for aviation use. Do not use data link graphical weather data as a substitute for airborne weather radar or thunderstorm detection equipment.
11.16 Database Accuracy and Quality. Database errors can have a significantly greater impact on the flightcrew member 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.
Databases utilizing raster aeronautical charts should use the guidance in RTCA DO-257A, Minimum Operational Performance Standards for the Depiction of Navigational Information on Electronic Maps, Appendix F, to determine the level of accuracy and resolution supported, as well as guidance on the appropriate use of colors for raster aeronautical charts. A means to identify the database version, effective date, and valid operating period must 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 of 50 meters accuracy is met. The 50-meter accuracy requirement 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. You may overlay EFB own-ship position on an EFB only when the installed primary flight display, weather 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 must ensure flight deck crewmembers understand the proper use of EFB own-ship position, including the need for concurrent use and differentiation. The flightcrew’s reference for maneuvering the aircraft in the air is the installed primary flight and navigational displays; therefore, they must be able to
16 resolve conflicts between the EFB information depicted on the “secondary” display and the installed avionics system identified for each EFB application as its reference for in-flight use. For EFB own-ship position use in ground operations, use of external visual references is sufficient for maneuvering.
11.17.2 EFB Own-Ship Display Supporting Requirements.
11.17.2.1 Position Source Selection. We recommend using 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 non-directional (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, 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 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: The display of EFB own-ship position on the airport surface as a Type B application 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 Map Zoom. Design of the application should 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
17 aircraft W&B. Type B W&B applications must 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 must not extrapolate, and therefore must 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. Type B performance applications must adhere to this published data and be validated for accurate determination of aircraft performance for the entire operating envelope. Type B aircraft performance 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 must not extrapolate beyond the information contained in the current published data. These algorithms must be tested and verified to meet existing FAA-approved AFM performance data. Type B performance applications must 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 Performance and W&B Applications. Type B 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 must be verified for accurate data selection. Applications based on algorithms calculating their output must 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 must adhere to the same data methodology as the FAA-approved AFM data. The Type B application must always be demonstrated to be traceable to the FAA-approved AFM data. These Type B applications must 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 must 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, must 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 must 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 must be addressed. Type B applications are suitable only insofar as they accurately reproduce the AFM data.
18 12 EFB PROGRAM COMPONENTS. A part 91K, 121, 125, or 135 operator must have an EFB program authorized by the FAA in order to use EFB applications on either portable or installed equipment in flight operations. EFB program specifics (i.e., operating procedures, maintenance procedures, administrative procedures, and training modules) must 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. An operator proposing to remove paper from the aircraft must 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 flightcrew member, not only the pilot or copilot.
12.2 Operational Procedures.
12.2.1 Operational Procedures for EFB Hardware and EFB Applications. EFB programs must contain operational procedures for the use of EFB hardware and EFB applications in the aircraft. These procedures must define the roles the flightcrew member, cabin crew, and dispatch/flight following, including but not limited to:
• Procedures defining expectations of how the flightcrew member must use each EFB application during ground operations and under all flight conditions.
• Procedures defining how the flightcrew member will report irregularities of EFB hardware or EFB applications and modify those existing policies and procedures based on flightcrew member feedback.
• Procedures for normal, abnormal, and emergency use to flightcrew members.
• Procedures for the notification of any changes to the EFB program.
Note: Normal procedures must address preflight assurance of an EFB’s preflight and/or flight planning use, in-flight use/stowage/power assurance, and shutdown procedures.
12.2.2 Procedures for Using EFBs with Other Flight Deck Systems. Procedures and training must 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 must address applicable type design considerations when an EFB is simultaneously displaying information with existing avionics displays, and procedures must identify which information source will be primary, and which source will be secondary. Whenever possible, the display of an EFB application must support existing flightdeck design philosophy while also ensuring the flightcrew member understands which system to use
19 for a given purpose, especially when installed avionics and EFBs are providing similar information.
12.2.3 Flightcrew Member Awareness of EFB Software/Database Revisions. The operator must have a procedure in place to allow flightcrew members 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 must specify what action to take if the applications or databases loaded on an EFB are out-of-date.
Note: Databases not adversely affecting flight 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 flightcrew members.
12.2.4 Procedures to Mitigate and/or Control Workload. Procedures must mitigate and/or control additional workloads created by using an EFB.
12.2.5 Defining Responsibilities for Performance/W&B Calculations. The operator must 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 must 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 upgrades and EFB OS upgrades may incorporate significant changes to flightcrew member 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 PI, 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 flightcrew members on each aircraft M/M/S and maintains configuration management of EFB program elements. An EFB program must have a process defined to keep the catalog current and readily available for PIs. A record must be maintained for any change to the EFB program catalog. The catalog must 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 must identify and track 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 must not adversely affect the EFB 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 must 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 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 Airmen (NOTAM) prior to departure and prior to arrival.
12.3.4 Database Update Process.
12.3.4.1 Databases. The operator must establish a method for revising EFB databases and establishing system verification with each update. The method of data revision must ensure 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 must exist to protect the EFB data from corruption. Database revisions do not include application software or OS changes. Operators must not perform database and/or application software changes during operations (i.e., 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 also need to establish revision control procedures so flightcrew members 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 must 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 must 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, must be kept for the life of the aircraft. The information (data) archived must be retrievable for the data
21 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 needs to 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 must provide the data in a format a requesting agency can use.
12.4 Maintenance Procedures. EFB programs must 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 must identify adequate security controls are in place to mitigate against the risk of unauthorized modifications 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; see 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 also needs to protect the EFB from possible contamination from malware. Evidence must 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 Level of EFB Security. The 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 assure the EFB can properly perform as intended, the level of security ultimately depends on the capabilities of the EFB, including connections to other systems. Security impacts of connections to aircraft systems must be addressed and special conditions may need to be addressed (refer to AC 20-173 for additional guidance).
12.5.3 Security Considerations. The following nonexhaustive list contains 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. Virtual private networks (VPN).
9. Granting of access rights on a need-to-have basis.
10. Troubleshooting procedures must consider security threats as a potential root cause of EFB misbehavior, and responses must be developed to prevent future successful attacks, when relevant.
11. Virtualization.
12. Forensic tools and procedures.
12.6 Operator Training. An EFB program must incorporate a means to train flightcrew members 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 airline.
• 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 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 is 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 personnel, loading personnel, and dispatchers. Training must emphasize the coordinated procedures with flightcrew members.
12.6.2 Training 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), FSB Report, OSR, or another form of documentation must be included in an operator’s training program. This additional documentation may contain the following, which must be addressed in training:
• Descriptions of authorized special flight maneuvers, operations, and procedures the operator conducts when using an EFB.
• 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 Practical 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 flightcrew members on the use of EFBs. If an EFB program is authorized, EFB use and performance in the full flight simulator (FFS) must represent actual flight operations.
12.7 Minimum Equipment Lists.
12.7.1 Portable EFBs. The Master Minimum Equipment List (MMEL) and MEL are not applicable to portable EFB hardware, or EFB applications. However, the loss of certain Type B EFB applications affecting operational regulatory requirements must be addressed in company procedures and program mitigation.
12.7.2 Installed EFBs. Installed hardware is subject to MMEL/MEL requirements. Changes made to the operator’s MEL must be made in accordance with the approved MMEL. An operator incorporating MMEL provisions into their MEL must comply with the provisions of the MEL.
12.8 Safety Management System (SMS). Part 121 operators must, while parts 91K and 135 operators are recommended to, 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.
13 EFB PROGRAM AUTHORIZATION. An operator under part 91K, 121, 125, or 135 seeking to develop an EFB program must submit an application for the applicable OpSpec/MSpec/letter of authorization (LOA) A061. FAA inspectors will use the following guidance in addition to this AC to evaluate and process the application for initial and program modifications:
• FAA Order 8900.1, Volume 4, Chapter 15, Electronic Flight Bag Program Evaluation and Authorization;
• FAA Order 8900.1, Volume 3, Chapter 1, The General Process for Approval or Acceptance of Air Operator Applications; and
• FAA Order 8900.1, Volume 3, Chapter 18, Section 3, Part A Operations Specifications—General.
13.1 Modifying an Authorized Program.
13.1.1 Minor Program Modifications. OpSpec/MSpec/LOA A061 authorizes operators to evaluate and incorporate minor modifications to their authorized EFB program without FAA review or assessment. Minor program modifications include:
• Adding/updating Type A EFB applications.
• Updating Type B EFB applications.
• Incorporating OS updates.
Note 1: Type B EFB application upgrades and EFB OS upgrades may incorporate significant changes to flightcrew member 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 PI, that it is minor.
Note 2: EMC testing may need to be performed, depending on the portable EFB EMC demonstration method utilized.
13.1.2 Significant Program Modifications. Modifications determined to be greater than minor program modifications require formal FAA review and evaluation before they can be authorized for incorporation into an EFB program. Unlike an evaluation of an initial EFB program application, applications for modifications to an authorized EFB program can be tailored at the discretion of the FAA inspector.
13.1.3 Non-EFB Applications and Other Proposals Not Addressed in This AC. Proposed EFB program modifications for the addition of applications not listed in Appendix A or B, or means of compliance not addressed in this AC, must be routed by the responsible Flight Standards office to the Future Flight Technologies Branch (AFS-430) for further evaluation, as specified in paragraph 8 of this AC.
13.2 Authorization Process for EFB Applications as Approved Software. Software with an airworthiness approval performing an EFB application may be utilized to support operational requirements without further PI evaluation of the software.
OpSpec/MSpec/LOA A061 is issued when all applicable EFB program requirements are considered satisfied.