SPA.EFB.100 Use of electronic flight bags (EFBs) – operational approval
Regulation (EU) 2018/1975
(a) A commercial air transport operator shall only use a type B EFB application if the operator has been granted an approval by the competent authority for such use.
(b) In order to obtain an operational approval from the competent authority for the use of a type B EFB application, the operator shall provide evidence that:
(1) a risk assessment related to the use of the EFB device that hosts the application and to the EFB application and its associated function(s) has been conducted, identifying the associated risks and ensuring that they are appropriately managed and mitigated;
(2) the human–machine interfaces of the EFB device and the EFB application have been assessed against human factors principles;
(3) it has established an EFB administration system and that procedures and training requirements for the administration and use of the EFB device and the EFB application have been established and implemented; these shall include procedures for:
(i) operating the EFB;
(ii) the management of changes to the EFB;
(iii) the management of EFB data;
(iv) EFB maintenance; and
(v) EFB security;
(4) the EFB host platform is suitable for the intended use of the EFB application.
This demonstration shall be specific to the EFB application and the EFB host platform on which the application is installed.
AMC1 SPA.EFB.100(b) Use of electronic flight bags (EFBs) – operational approval
ED Decision 2019/008/R
(a) Placement of the display
The placement of the display should be consistent with the intended use of the EFB and should not create unacceptable workload for the pilot or require undue ‘head-down’ movements during critical phases of flight. Displays used for EFB chart applications should be located so as to be visible from the pilot’ station with the minimum practicable deviation from their lines of vision when looking forward along the flight path.
(b) Display characteristics
Consideration should be given to the long-term degradation of a display as a result of abrasion and ageing. AMC 25-11 (paragraph 3.16a) may be used as guidance to assess luminance and legibility aspects.
Information displayed on the EFB should be legible to the typical user at the intended viewing distance(s) and under the full range of lighting conditions expected in a flight crew compartment, including direct sunlight.
Users should be able to adjust the screen brightness of an EFB independently of the brightness of other displays in the flight crew compartment. In addition, when incorporating an automatic brightness adjustment, it should operate independently for each EFB in the flight crew compartment. Brightness adjustment using software means may be acceptable provided that this operation does not adversely affect the flight crew workload.
Buttons and labels should have adequate illumination for night use. ‘Buttons and labels’ refers to hardware controls located on the display itself.
All controls should be properly labelled for their intended functions, except if no confusion is possible.
The 90-degree viewing angle on either side of each flight crew member’s line of sight may be unacceptable for certain EFB applications if aspects of the display quality are degraded at large viewing angles (e.g. the display colours wash out or the displayed colour contrast is not discernible at the installation viewing angle).
(c) Power source
The design of a portable EFB system should consider the source of electrical power, the independence of the power sources for multiple EFBs, and the potential need for an independent battery source. A non-exhaustive list of factors to be considered includes:
(1) the possibility to adopt operational procedures to ensure an adequate level of safety (for example, a minimum preflight level of charge);
(2) the possible redundancy of portable EFBs to reduce the risk of exhausted batteries;
(3) the availability of backup battery packs to ensure that there is an alternative source of power.
Battery-powered EFBs that have aircraft power available for recharging the internal EFB batteries are considered to have a suitable backup power source.
For EFBs that have an internal battery power source, and that are used as an alternative for paper documentation that is required by CAT.GEN.MPA.180, the operator should either have at least one EFB connected to an aircraft power bus, or have established and documented mitigation means and procedures to ensure that sufficient power with acceptable margins will be available during the whole flight.
(d) Environmental testing
Environmental testing, in particular testing for rapid decompression, should be performed on EFBs that host applications that are required to be used during flight following a rapid decompression, and/or on EFBs with an environmental operational range that is potentially insufficient with respect to the foreseeable flight crew compartment operating conditions.
The information from the rapid-decompression test of an EFB is used to establish the procedural requirements for the use of that EFB device in a pressurised aircraft. Rapid-decompression testing should follow the EUROCAE ED-14D/RTCA DO-160D (or later revisions) guidelines for rapid-decompression testing up to the maximum operating altitude of the aircraft at which the EFB is to be used.
(1) Pressurised aircraft: if a portable EFB has successfully completed rapid-decompression testing, then no mitigating procedures for depressurisation events need to be developed. If a portable EFB has failed the rapid-decompression testing while turned ON, but successfully completed it when turned OFF, then procedures should ensure that at least one EFB on board the aircraft either remains OFF during the applicable flight phases, or is configured so that no damage will be incurred should rapid decompression occur in flight at altitudes higher than 10 000 ft above mean sea level (AMSL).
If an EFB system has not undergone a rapid-decompression test or it has failed the test, then alternate procedures or a paper backup should be available for the related type B EFB applications.
(2) Non-pressurised aircraft: rapid-decompression testing is not required for an EFB used in a non pressurised aircraft. It should be demonstrated that the EFB can operate reliably up to the maximum operating altitude of the aircraft. If the EFB cannot be operated at the maximum operating altitude of the aircraft, procedures should be established to preclude operation of the EFB above the maximum demonstrated EFB operating altitude while still maintaining the availability of any required aeronautical information displayed on the EFB.
The results of testing performed on a specific EFB model configuration (as identified by the EFB hardware manufacturer) may be applicable to EFBs of the same model used in other aircraft installations, in which case these generic environmental tests may not need to be duplicated. The operator should collect and retain:
(1) evidence of these tests that have already been accomplished; or
(2) suitable alternative procedures to deal with the total loss of the EFB system.
Rapid decompression tests do not need to be repeated if the EFB model identification and the battery type do not change.
The testing of operational EFBs should be avoided if possible to preclude the infliction of unknown damage to the devices during testing.
Operators should account for the possible loss or erroneous functioning of the EFB in abnormal environmental conditions.
The safe stowage and the use of the EFB under any foreseeable environmental conditions in the flight crew compartment, including turbulence, should be evaluated.
CHANGES
Modifications to an EFB system may have to be introduced either by the EFB system supplier, the EFB applications developer, or by the operator itself.
Those modifications that:
(a) do not result in a hardware change that would require a re-evaluation of the HMI and human factors aspects in accordance with AMC1 SPA.EFB.100(b)(2);
(b) do not bring any change to the calculation algorithms of a type B EFB application;
(c) do not bring any change to the HMI of a type B EFB application that requires a change to the flight crew training programme or operational procedures;
(d) introduce a new type A EFB application or modify an existing one (provided its software classification remains type A);
(e) do not introduce any additional functionality to an existing type B EFB application; or
(f) update an existing database necessary to use an existing type B EFB application,
may be introduced by the operator without the need to be approved by its competent authority.
These changes should, nevertheless, be controlled and properly tested prior to use during flights.
The modifications in the following non-exhaustive list are considered to meet these criteria:
(a) operating system updates;
(b) chart or airport database updates;
(c) updates to introduce fixes (i.e. patches); and
(d) installation and modification of a type A EFB application.
For all other types of modification, the operator should apply the change management procedure approved by the competent authority in accordance with ARO.GEN.310(c). This includes the extension of the use of an EFB system, for which the operator already holds an approval, to another aircraft type of the operator’s fleet.
In the specific case of a complete change of the hardware hosting the EFB application, the operator should demonstrate to its competent authority that the new hardware is suitable for the intended use of the EFB application as per AMC1 SPA.EFB.100(b).
OPERATIONAL EVALUATION TEST
(a) The operator should perform an operational evaluation test which should enable verification that the relevant requirements of SPA.EFB have been satisfied before a final decision is made on the operational use of the EFB.
An operational evaluation test should be performed by operators seeking an operational approval for the use of a type B EFB application. This does not apply to changes to a type B EFB application whose use has already been approved by the operator’s competent authority.
The operator should notify its competent authority of its intention to perform an operational evaluation test by providing a plan, which should contain at least the following information:
(1) the starting date of the operational evaluation test;
(2) the duration of the operational evaluation test;
(3) the aircraft involved;
(4) the EFB hardware and type(s) of software including version details;
(5) the EFB policy and procedure manual;
(6) their EFB risk assessment; and
(7) for type B EFB applications that replace the paper documentation without initial retention of a paper backup, and type B EFB applications that do not replace the paper documentation:
(i) a simulator line-oriented flight training (LOFT) session programme to verify the use of the EFB under operational conditions including normal, abnormal, and emergency conditions; and
(ii) a proposed schedule to allow the competent authority to observe the EFB application use in actual flight operations.
The operational evaluation test should consist of an in-service proving period with a standard duration of 6 months. A reduced duration may be considered after taking into account the following criteria:
(1) the operator’s previous experience with EFBs;
(2) a high number of flights operated monthly;
(3) the intended use of the EFB system; and
(4) the mitigation means defined by the operator.
An operator wishing to reduce the duration of the operational evaluation test to less than 6 months should provide its competent authority with the appropriate justification in its operational evaluation plan.
The competent authority may ask for an operational evaluation test lasting more than 6 months if the number of flights operated in this period is not considered sufficient to evaluate the EFB system.
The general purpose of the in-service proving period for type B EFB applications that replaces the paper documentation is for the operator to demonstrate that an EFB system provides at least the levels of accessibility, usability and reliability of the paper documentation.
For all type B EFB applications, the proving period should show that:
(1) the flight crew members are able to operate the EFB applications;
(2) the operator’s administration procedures are in place and function correctly;
(3) the operator is capable of providing timely updates to the applications on the EFB, where a database is involved;
(4) the introduction of the EFB does not adversely affect the operator’s operating procedures, and that alternative procedures provide an acceptable equivalent if the EFB system is not available;
(5) for a system including uncertified elements (hardware or software), that the system operates correctly and reliably; and
(6) the assumptions used for the risk assessment are not disproved for the type of operations intended (with or without a paper backup).
In the case of charts or in-flight weather (IFW) applications displaying the own-ship position in flight, the in-service proving should allow to confirm the absence of frequent losses of position and to assess the resulting workload for the flight crew.
The operator may remove the paper backup once it has shown that the EFB system is sufficiently robust.
(b) Final operational report
The operator should produce and retain a final operational report, that summarises all the activities performed and the means of compliance that were used, supporting the operational use of the EFB system.
EFB APPLICATIONS WITH ETSO AUTHORISATIONS
EFB software applications may be approved by EASA e.g. by means of an ETSO authorisation. Such approved EFB applications are considered to be compliant with the requirements of SPA.EFB.100(b) that are included in the scope of the approval, provided that the EFB software is installed and used in conformity with its installation and operational instructions and limitations.
FINAL OPERATIONAL REPORT
An example of typical items for the final operational report is provided below:
(a) System description and classification of the EFB system:
(1) a general description of the EFB system and of the hardware and software applications.
(b) Software applications:
(1) a list of the type A EFB applications installed;
(2) a list of the type B EFB applications installed; and
(3) a list of the miscellaneous software applications installed.
(c) Hardware:
For portable EFBs used without installed resources, relevant information about or reference to:
(1) the EMI compliance demonstration;
(2) the lithium battery compliance demonstration;
(3) the depressurisation compliance demonstration; and
(4) details of the power source.
For portable EFBs served by installed resources:
(1) details of the airworthiness approval for the mounting device;
(2) a description of the placement of the EFB display;
(3) details of the use of installed resources;
(4) information on the EMI compliance demonstration;
(5) information on the lithium battery compliance demonstration;
(6) information on the depressurisation compliance demonstration;
(7) details of the power source;
(8) details of any data connectivity.
For installed EFBs:
(1) details of the airworthiness approval for installed equipment.
(d) Certification documentation:
(1) EFB limitations contained within the AFM;
(2) guidelines for EFB application developers; and
(3) guidelines for EFB system suppliers.
(e) Specific considerations for performance applications:
(1) details of performance data validation performed.
(f) Operational assessment:
(1) details of the EFB risk assessment performed;
(2) details of the human–machine interface (HMI) assessment performed for type B EFB applications;
(3) details of flight crew operating procedures:
(i) for using EFB systems with other flight crew compartment systems;
(ii) ensuring flight crew awareness of EFB software/database revisions;
(iii) to mitigate and/or control increased workload; and
(iv) describing flight crew responsibilities for performance and weight and balance calculations;
(4) details of proposed compliance monitoring oversight of the EFB system;
(5) details of EFB system security measures;
(6) details of EFB administration procedures, including provision of the EFB policy and procedures manual and EFB administrator qualifications;
(7) details of the procedure for electronic signatures;
(8) details of the system for routine EFB system maintenance;
(9) details of EFB training including flight crew training:
(i) initial training;
(ii) differences training; and
(iii) recurrent training;
(10) Report of the operational evaluation test:
(i) proposals for the initial retention of a paper backup;
(ii) proposals for the commencement of operations without any paper backup;
(11) EFB platform/hardware description;
(12) a description of each software application to be included in the assessment;
(13) a human factors assessment for the complete EFB system, human–machine interface (HMI), and all the software applications that covers:
(i) the flight crew workload in both single-pilot and multi-pilot aircraft;
(ii) the size, resolution, and legibility of symbols and text;
(iii) for navigation chart displays: access to desired charts, access to information within a chart, grouping of information, general layout, orientation (e.g. track-up, north-up), depiction of scale information.
EVALUATION BY EASA
The operator may use the results of an EFB application evaluation performed by EASA to support its application to its competent authority for an operational approval.
RISK ASSESSMENT
(a) General
Prior to the use of any EFB system, the operator should perform a risk assessment for all type B EFB applications and for the related EFB hardware, as part of its hazard identification and risk management process.
If an operator makes use of a risk assessment established by the software developer, the operator should ensure that its specific operational environment is taken into account.
The risk assessment should:
(1) evaluate the risks associated with the use of an EFB;
(2) identify potential losses of function or malfunction (with detected and undetected erroneous outputs) and the associated failure scenarios;
(3) analyse the operational consequences of these failure scenarios;
(4) establish mitigating measures; and
(5) ensure that the EFB system (hardware and software) achieves at least the same level of accessibility, usability, and reliability as the means of presentation it replaces.
In considering the accessibility, usability, and reliability of the EFB system, the operator should ensure that the failure of the complete EFB system, as well as of individual applications, including corruption or loss of data, and erroneously displayed information, has been assessed and that the risks have been mitigated to an acceptable level.
This risk assessment should be defined before the beginning of the trial period and should be amended accordingly, if necessary, at the end of this trial period. The results of the trial should establish the configuration and use of the system. Once the operator has been granted the operational approval for the use of the related EFB applications, it should ensure that the related risk assessment is maintained and kept up to date.
When the EFB system is intended to be introduced alongside a paper-based system, only the failures that would not be mitigated by the use of the paper-based system need to be addressed. In all other cases, and especially when an accelerated introduction with a reduced trial period or a paperless use of a new EFB system is intended, a complete risk assessment should be performed.
(b) Assessing and mitigating the risks
Some parameters of EFB applications may depend on entries that are made by flight crew/dispatchers, whereas others may be default parameters from within the system that are subject to an administration process (e.g. the runway line-up allowance in an aircraft performance application). In the first case, mitigation means would mainly concern training and flight crew procedure aspects, whereas in the second case, mitigation means would more likely focus on the EFB administration and data management aspects.
The analysis should be specific to the operator concerned and should address at least the following points:
(1) The minimisation of undetected erroneous outputs from applications and assessment of the worst credible scenario;
(2) Erroneous outputs from the software application, including:
(i) a description of the corruption scenarios that were analysed; and
(ii) a description of the mitigation means;
(3) Upstream processes including:
(i) the reliability of root data used in applications (e.g. qualified input data, such as databases produced under ED-76/DO-200A, ‘Standards for Processing Aeronautical Data’);
(ii) the software application validation and verification checks according to relevant industry standards, if applicable; and
(iii) the independence between application software components, e.g. robust partitioning between EFB applications and other airworthiness certified software applications;
(4) A description of the mitigation means to be used following the detected failure of an application, or of a detected erroneous output;
(5) The need for access to an alternate power supply in order to ensure the availability of software applications, especially if they are used as a source of required information.
As part of the mitigation means, the operator should consider establishing reliable alternative means to provide the information available on the EFB system.
The mitigation means could be, for example, one of, or a combination of, the following:
(1) the system design (including hardware and software);
(2) a backup EFB device, possibly supplied from a different power source;
(3) EFB applications being hosted on more than one platform;
(4) a paper backup (e.g. quick reference handbook (QRH)); and
(5) procedural means.
EFB system design features such as those assuring data integrity and the accuracy of performance calculations (e.g. a ‘reasonableness’ or ‘range’ check) may be integrated in the risk assessment to be performed by the operator.
HUMAN–MACHINE INTERFACE ASSESSMENT AND HUMAN FACTORS CONSIDERATIONS
(a) The operator should perform an assessment of the human–machine interface (HMI), the installation, and aspects governing crew resource management (CRM) when using the EFB system.
The HMI assessment is key to identifying acceptable mitigation means, e.g.:
(1) to establish procedures for reducing the risk of making errors; and
(2) to control and mitigate the additional workload related to EFB use.
(b) The assessment should be performed by the operator for each kind of device and application installed on the EFB. The operator should assess the integration of the EFB into the flight deck environment, considering both physical integration (e.g. anthropometrics, physical interference, etc.) and cognitive ergonomics (the compatibility of look and feel, workflows, alerting philosophy, etc.).
(1) Human–machine interface
The EFB system should provide a consistent and intuitive user interface within and across the various hosted applications and with flight deck avionics applications. This should include but is not limited to data entry methods, colour-coding philosophies, and symbology.
(2) Input devices
When choosing and designing input devices such as keyboards or cursor-control devices, applicants should consider the type of entry to be made and also flight crew compartment environmental factors, such as turbulence, that could affect the usability of that input device. Typically, the performance parameters of cursor-control devices should be tailored for the function of the intended application as well as for the flight crew compartment environment.
(3) Consistency
(i) Consistency between EFBs and applications:
Particular attention should be paid to the consistency of all interfaces, in particular when one provider develops the software application and another organisation integrates it into the EFB.
(ii) Consistency with flight deck applications:
Whenever possible, EFB user interfaces should be consistent with the other flight deck avionics applications with regard to design philosophy, look and feel, interaction logic, and workflows.
(4) Messages and the use of colours
For any EFB system, EFB messages and reminders should be readily and easily detectable and intelligible by the flight crew under all foreseeable operating conditions.
The use of red and amber colours should be limited and carefully considered. EFB messages, both visual and aural, should be, as far as practicable, inhibited during critical phases of the flight.
Flashing text or symbols should be avoided in any EFB application. Messages should be prioritised according to their significance for the flight crew and the message prioritisation scheme should be documented in the operator’s EFB policy and procedure manual.
Additionally, during critical phases of the flight, information necessary to the pilot should be continuously presented without uncommanded overlays, pop-ups, or pre-emptive messages, except for those indicating the failure or degradation of the current EFB application. However, if there is a regulatory or technical standard order (TSO) requirement that is in conflict with the recommendation above, that requirement should take precedence.
(5) System error messages
If an application is fully or partially disabled or is not visible or accessible to the user, it may be desirable to have an indication of its status available to the user upon request. Certain non-essential applications such as those for email connectivity and administrative reports may require an error message when the user actually attempts to access the function, rather than an immediate status annunciation when a failure occurs. EFB status and fault messages should be documented in the operator’s EFB policy and procedure manual.
(6) Data entry screening and error messages
If any user-entered data is not of the correct format or type needed by the application, the EFB should not accept the data. An error message should be provided that communicates which entry is suspect and specifies what type of data is expected. The EFB system should incorporate input error checking that detects input errors at the earliest possible point during entry, rather than on completion of a possibly lengthy invalid entry.
(7) Error and failure modes
(i) Flight crew errors:
The system should be designed to minimise the occurrence and effects of flight crew errors and to maximise the identification and resolution of errors. For example, terms for specific types of data or the format in which latitude/longitude is entered should be the same across systems.
(ii) Identifying failure modes:
The EFB system should alert the flight crew of EFB system failures.
(8) Responsiveness of applications
The EFB system should provide feedback to the user when a user input is performed. If the system is busy with internal tasks that preclude the immediate processing of a user input (e.g. performing calculations, self-tests, or refreshing data), the EFB should display a ‘system busy’ indicator (e.g. a clock icon) to inform the user that the system is occupied and cannot process inputs immediately.
The timeliness of the EFB system response to a user input should be consistent with an application’s intended function. The feedback and system response times should be predictable in order to avoid flight crew distractions and/or uncertainty.
(9) Off-screen text and content
If the document segment is not visible in its entirety in the available display area, such as during ‘zoom’ or ‘pan’ operations, the existence of off-screen content should be clearly indicated in a consistent way. For some intended functions, it may be unacceptable if certain portions of documents are not visible. Also, some applications may not require an off-screen content indicator when the presence of off screen content is readily obvious. This should be evaluated based on the application and its intended operational function. If there is a cursor, it should be visible on the screen at all times while in use.
(10) Active regions
Active regions are regions to which special user commands apply. The active region can be text, a graphic image, a window, frame, or some other document object. These regions should be clearly indicated.
(11) Managing multiple open applications and documents
If the electronic document application supports multiple open documents, or the system allows multiple open applications, an indication of which application and/or document is active should be continuously provided. The active document is the one that is currently displayed and responds to user actions. The user should be able to select which of the open applications or documents is currently active. In addition, the user should be able to find which flight crew compartment applications are running and easily switch to any of these applications. When the user returns to an application that was running in the background, it should appear in the same state as when the user left that application, with the exception of differences stemming from the progress or completion of processing performed in the background.
(12) Flight crew workload
The positioning of the EFB and the procedures associated with its use should not result in undue flight crew workload. Complex, multi-step-data-entry tasks should be avoided during take-off, landing, and other critical phases of the flight. An evaluation of the EFB intended functions should include a qualitative assessment of the incremental flight crew workload, as well as the flight crew system interfaces and their safety implications.
EFB ADMINISTRATOR
The operator should appoint an EFB administrator responsible for the administration of the EFB system within the operator’s organisation. The EFB administrator is the primary link between the operator and the EFB system and software suppliers.
The EFB administrator function may be contracted to an external organisation in accordance with ORO.GEN.205.
Complex EFB systems may require more than one individual with appropriate authority within the operator’s management structure to perform the administration process, but one person should be designated as the EFB administrator responsible for the complete system.
The EFB administrator is the person in overall charge of the EFB system, and should be responsible for ensuring that any hardware conforms to the required specification, and that no unauthorised software is installed. They should also be responsible for ensuring that only the current versions of the application software and data packages are installed on the EFB system.
The EFB administrator should be responsible:
(a) For all the EFB applications installed, and for providing support to the EFB users regarding these applications;
(b) For checking potential security issues associated with the applications installed;
(c) For hardware and software configuration management of the EFBs, and, in particular, for ensuringthat no unauthorised software is installed.
The EFB administrator should ensure that miscellaneous software applications do not adversely impact on the operation of the EFB and should include miscellaneous software applications in the scope of the configuration management of the EFB.
This does not preclude EFB devices from being allocated to specific flight crew members.
In those cases where it is demonstrated that miscellaneous software applications run in a way that is fully segregated and partitioned from the EFB or avionics applications (e.g. on a separate operating system on a distinct ‘personal’ hard drive partition that is selected when the EFB boots up), the administration of these miscellaneous software applications can be exercised by the flight crew members instead of by the EFB administrator.
(d) For ensuring that only valid versions of the application software and current data packages are installed on the EFB system; and
(e) For ensuring the integrity of the data packages used by the applications installed.
The operator should make arrangements to ensure the continuity of the management of the EFB system in the absence of the EFB administrator.
Each person involved in EFB administration should receive appropriate training for their role and should have a good knowledge of the proposed system hardware, operating system and relevant software applications, and also of the appropriate regulatory requirements related to the use of EFBs. The content of this training should be determined with the aid of the EFB system supplier or application supplier.
The operator should ensure that the persons involved in EFB administration keep their knowledge about the EFB system and its security up to date.
EFB POLICY AND PROCEDURES MANUAL
The operator should establish procedures, documented in an EFB policy and procedures manual, to ensure that no unauthorised changes take place. The EFB policy and procedures manual may be fully or partially integrated in the operations manual.
The EFB policy and procedures manual should also address means to ensure that the content and databases of the EFB are valid and up to date, in order to ensure the integrity of the EFB data. This may include establishing revision-control procedures so that flight crew members and others can ensure that the contents of the system are current and complete. These revision control procedures may be similar to the revision control procedures used for paper or other storage means.
The EFB policy and procedures manual should also clearly identify those parts of the EFB system that can be accessed and modified by the operator’s EFB administration process and those parts that are only accessible by the EFB system supplier.
For data that is subject to a revision cycle control process, it should be readily evident to the user which revision cycle has been incorporated in the information obtained from the system. Procedures should specify what action to take if the applications or databases loaded on the EFB are outdated. This manual should at least include the following:
(a) All EFB-related procedures, including:
(1) operating procedures;
(2) security procedures;
(3) maintenance procedures;
(4) software control procedures;
(b) Management of changes to content/databases;
(c) Notifications to crews of updates;
(d) If any applications use information that is specific to the aircraft type or tail number, guidance on how to ensure that the correct information is installed on each aircraft;
(e) Procedures to avoid corruption/errors when implementing changes to the EFB system; and
(f) In cases involving multiple EFBs in the flight crew compartment, procedures to ensure that they all have the same content/databases installed.
The EFB administrator should be responsible for the procedures and systems documented in the EFB policy and procedures manual that maintain EFB security and integrity. This includes system security, content security, access security, and protection against malicious software.
PROCEDURES
(a) General
If an EFB system generates information similar to that generated by existing certified systems, procedures should clearly identify which information source will be the primary, which source will be used for backup information, and under which conditions the backup source should be used. Procedures should define the actions to be taken by the flight crew when information provided by an EFB system is not consistent with that from other flight crew compartment sources, or when one EFB system shows different information than the other.
In the case of EFB applications providing information which might be affected by Notice(s) to Airmen NOTAMS (e.g. Airport moving map display (AMMD), performance calculation, etc.), the procedure for the use of these applications should include the handling of the relevant NOTAMS before their use.
(b) Flight crew awareness of EFB software/database revisions
The operator should have a procedure in place to verify that the configuration of the EFB, including software application versions and, where applicable, database versions, are up to date. Flight crew members should have the ability to easily verify the validity of database versions used on the EFB. Nevertheless, flight crew members should not be required to confirm the revision dates for other databases that do not adversely affect flight operations, such as maintenance log forms or a list of airport codes. An example of a date-sensitive revision is that applied to an aeronautical chart database. Procedures should specify what actions should be taken if the software applications or databases loaded on the EFB system are outdated.
(c) Procedures to mitigate and/or control workload
Procedures should be designed to mitigate and/or control additional workload created by using an EFB system. The operator should implement procedures to ensure that, while the aircraft is in flight or moving on the ground, flight crew members do not become preoccupied with the EFB system at the same time. Workload should be shared between flight crew members to ensure ease of use and continued monitoring of other flight crew functions and aircraft equipment. These procedures should be strictly applied in flight and the operator should specify any times when the flight crew may not use a specific EFB application.
(d) Dispatch
The operator should establish dispatch criteria for EFB systems. The operator should ensure that the availability of the EFB system is confirmed by preflight checks. Instructions to the flight crew should clearly define the actions to be taken in the event of any EFB system deficiency.
Mitigation should be in the form of maintenance and/or operational procedures for items such as:
(1) replacement of batteries at defined intervals as required;
(2) ensuring there is a fully charged backup battery on board;
(3) the flight crew checking the battery charging level before departure; and
(4) the flight crew switching off the EFB in a timely manner when the aircraft power source is lost.
In the event of a partial or complete failure of the EFB, specific dispatch procedures should be followed. These procedures should be included either in the minimum equipment list (MEL) or in the operations manual, and should ensure an acceptable level of safety.
Particular attention should be paid to establishing specific dispatch procedures allowing to obtain operational data (e.g. performance data) in case of a failure of an EFB hosting an application that normally provides such calculated data.
When the integrity of data input and output is verified by cross-checking and gross-error checks, the same checking principle should be applied to alternative dispatch procedures to ensure equivalent protection.
(e) Maintenance
Procedures should be established for the routine maintenance of the EFB system and detailing how unserviceability and failures are to be dealt with to ensure that the integrity of the EFB system is preserved. Maintenance procedures should also include the secure handling of updated information and how this information is validated and then promulgated in a timely manner and in a complete format to all users.
As part of the EFB system’s maintenance, the operator should ensure that the EFB system batteries are periodically checked and replaced as required.
Should faults or failures of the system arise, it is essential that such failures are brought to the immediate attention of the flight crew and that the system is isolated until rectification action is taken. In addition to backup procedures to deal with system failures, a reporting system should be in place so that the necessary corrective action, either to a particular EFB system or to the whole system, is taken in order to prevent the use of erroneous information by flight crew members.
(f) Security
The EFB system (including any means used for updating it) should be secure from unauthorised intervention (e.g. by malicious software). The operator should ensure that adequate security procedures are in place to protect the system at the software level and to manage the hardware (e.g. the identification of the person to whom the hardware is released, protected storage when the hardware is not in use) throughout the operational lifetime of the EFB system. These procedures should guarantee that, prior to each flight, the EFB operational software works as specified and the EFB operational data is complete and accurate. Moreover, a system should be in place to ensure that the EFB does not accept a data load that contains corrupted contents. Adequate measures should be in place for the compilation and secure distribution of data to the aircraft.
Procedures should be transparent and easy to understand to follow and to oversee that:
(1) if an EFB is based on consumer electronics (e.g. a laptop) which can be easily removed, manipulated, or replaced by a similar component, that special consideration is given to the physical security of the hardware;
(2) portable EFB platforms are subject to allocation tracking to specific aircraft or persons;
(3) where a system has input ports, and especially if widely known protocols are used through these ports, or internet connections are offered, that special consideration is given to the risks associated with these ports;
(4) where physical media are used to update the EFB system, and especially if widely known types of physical media are used, that the operator uses technologies and/or procedures to assure that unauthorised content cannot enter the EFB system through these media.
The required level of EFB security depends on the criticality of the functions used (e.g. an EFB that only holds a list of fuel prices may require less security than an EFB used for performance calculations).
Beyond the level of security required to assure that the EFB can properly perform its intended functions, the level of security that is ultimately required depends on the capabilities of the EFB.
(g) Electronic signatures
Part-CAT and Part-M may require a signature when issuing or accepting a document (e.g. load sheet, technical logbook, notification to captain (NOTOC)). In order to be accepted as being equivalent to a handwritten signature, electronic signatures used in EFB applications need, as a minimum, to fulfil the same objectives and to assure the same degree of security as the handwritten or any other form of signature that they are intended to replace. AMC1 CAT.POL.MAB.105(c) provides the means to comply with the required handwritten signature or its equivalent for mass and balance documentation.
On a general basis, in the case of required signatures, an operator should have in place procedures for electronic signatures that guarantee:
(1) their uniqueness: a signature should identify a specific individual and should be difficult to duplicate;
(2) their significance: an individual using an electronic signature should take deliberate and recognisable action to affix their signature;
(3) their scope: the scope of the information being affirmed with an electronic signature should be clear to the signatory and to the subsequent readers of the record, record entry, or document;
(4) their security: the security of an individual’s handwritten signature is maintained by ensuring that it is difficult for another individual to duplicate or alter it;
(5) their non-repudiation: an electronic signature should prevent a signatory from denying that they affixed a signature to a specific record, record entry, or document; the more difficult it is to duplicate a signature, the likelier it is that the signature was created by the signatory; and
(6) their traceability: an electronic signature should provide positive traceability to the individual who signed a record, record entry, or any other document.
An electronic signature should retain those qualities of a handwritten signature that guarantee its uniqueness. Systems using either a PIN or a password with limited validity (timewise) may be appropriate in providing positive traceability to the individual who affixed it. Advanced electronic signatures, qualified certificates and secured signature-creation devices needed to create them in the context of Regulation (EU) No 910/201488 Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC (OJ L 257, 28.8.2014, p. 73). are typically not required for EFB operations.
FLIGHT CREW TRAINING
(a) Flight crew members should be given specific training on the use of the EFB system before it is operationally used.
Training should at least include the following:
(1) an overview of the system architecture;
(2) preflight checks of the system;
(3) limitations of the system;
(4) specific training on the use of each application and the conditions under which the EFB may and may not be used;
(5) restrictions on the use of the system, including cases where the entire system, or some parts of it, are not available;
(6) procedures for normal operations, including cross-checking of data entry and computed information;
(7) procedures to handle abnormal situations, such as a late runway change or a diversion to an alternate aerodrome;
(8) procedures to handle emergency situations;
(9) phases of the flight when the EFB system may and may not be used;
(10) human factors considerations, including crew resource management (CRM), on the use of the EFB; and
(11) additional training for new applications or changes to the hardware configuration.
As far as practicable, it is recommended that the training simulator environments should include the EFBs in order to offer a higher level of representativeness.
Consideration should also be given to the role that the EFB system plays in operator proficiency checks as part of recurrent training and checking, and to the suitability of the training devices used during training and checking.
EFB training should be included in the relevant training programme established and approved in accordance with ORO.FC.
(b) EFB training and checking
(1) Assumptions regarding flight crew members’ previous experience
Training for the use of the EFB should be for the purpose of operating the EFB itself and the applications hosted on it, and should not be intended to provide basic competence in areas such as aircraft performance, etc. Initial EFB training, therefore, should assume basic competence in the functions addressed by the software applications installed.
Training should be adapted to the flight crew’s experience and knowledge.
(2) Programmes crediting previous EFB experience
Training programmes for the EFB may give credit for trainees’ previous EFB experience. For example, previous experience of an aircraft performance application hosted on a portable EFB and using similar software may be credited towards training on an installed EFB with a performance application.
(3) Initial EFB training
Training required for the granting of an aircraft type rating may not recognise variants within the type nor the installation of particular equipment. Any training for the granting of a type qualification need not, therefore, recognise the installation or the use of an EFB unless it is installed equipment across all variants of the type. However, where training for the issuing of the type rating is combined with the operator’s conversion course, the training syllabus should recognise the installation of the EFB where the operator’s standard operating procedures (SOPs) are dependent on its use.
Initial EFB training may consist of both ground-based and flight training, depending on the nature and complexity of the EFB system. An operator or approved training organisation (ATO) may use many methods for ground-based EFB training including written handouts or flight crew operating manual (FCOM) material, classroom instruction, pictures, videotapes, ground training devices, computer-based instruction, flight simulation training devices (FSTDs), and static aircraft training. Ground-based training for a sophisticated EFB lends itself particularly to computer-based training (CBT). Flight EFB training should be performed by a suitably qualified person during line flying under supervision (LIFUS) or during differences or conversion training.
The following areas of emphasis should be considered when defining the initial EFB training programme:
(i) The use of the EFB hardware and the need for proper adjustment of lighting, etc., when the system is used in flight;
(ii) The intended use of each software application together with any limitations or prohibitions on its use;
(iii) Proper cross-checking of data inputs and outputs if an aircraft performance application is installed,;
(iv) Proper verification of the applicability of the information being used if a terminal chart application is installed;
(v) The need to avoid fixation on the map display if a moving map display is installed;;
(vi) Handling of conflicting information;
(vii) Failures of component(s) of the EFB; and
(viii) Actions to be taken following the failure of component(s) of the EFB, including cases of battery smoke or fire.
(4) Initial EFB checking
(i) Initial ground EFB checking
The check performed following the ground-based element of initial EFB training may be accomplished by the use of a questionnaire (oral or written) or as an automated component of the EFB CBT, depending on the nature of the training performed.
(ii) Skill test and proficiency check
Where the operator’s SOPs are dependent on the use of the EFB on the particular aircraft type or variant, proficiency in the use of the EFB should be assessed in the appropriate areas (e.g. item 1.1, item 1.5, etc., of Appendix 9 to Annex I (Part-FCL) to Commission Regulation (EU) No 1178/2011).
(iii) Operator proficiency check
Where an operator’s SOPs are dependent on the use of an EFB, proficiency in its use should be assessed during the operator proficiency check (OPC). Where the OPC is performed on an FSTD not equipped with the operator’s EFB, proficiency should be assessed by another acceptable means.
(iv) Line check
Where an operator’s SOPs are dependent on the use of an EFB, proficiency in its use should be assessed during a line check.
(v) Areas of emphasis during EFB checking:
(A) Proficiency in the use of each EFB application installed;
(B) Proper selection and use of EFB displays;
(C) Where an aircraft performance application is installed, proper cross-checking of data inputs and outputs;
(D) Where a chart application is installed, proper checking of the validity of the information and the use of the chart clip function;
(E) Where a moving map display is installed, maintenance of a proper outside visual scan without prolonged fixation on the EFB, especially during taxiing; and
(F) Actions to be taken following the failure of component(s) of the EFB, including cases of battery smoke or fire.
(c) Differences or familiarisation training
When the introduction of the use of an EFB requires differences or familiarisation training to be carried out, the elements of initial EFB training should be used, as described above.
(d) Recurrent EFB training and checking
(1) Recurrent EFB training
Recurrent training is normally not required for the use of an EFB, provided the functions are used regularly in line operations. Operators should, however, include normal EFB operations as a component of the annual ground and refresher training.
In the case of mixed-fleet operations, or where the EFB is not installed across the fleet, additional recurrent training should be provided.
(2) Recurrent EFB checking
Recurrent EFB checking should be integrated in those elements of the licence proficiency check, the operator proficiency check and the line check applicable to the use of an EFB.
(e) Suitability of training devices
Where the operator’s SOPs are dependent on the use of an EFB, the EFB should be present during the operator’s training and checking. Where present, the EFB should be configured and operable in all respects as per the relevant aircraft. This should apply to:
(1) the operator’s conversion course;
(2) differences or familiarisation training; and
(3) recurrent training and checking.
Where the EFB system is based on a portable device used without any installed resources, it is recommended that the device should be present, operable, and used during all phases of the flight during which it would be used under the operator’s SOPs.
For all other types of EFB systems, it is recommended that the device should be installed and operable in the training device (e.g. an FFS) and used during all phases of the flight during which it would be used under the operator’s SOPs. However, an operator may define an alternative means of compliance when the operator’s EFB system is neither installed nor operable in the training device.
Note: It is not necessary for the EFB to be available for those parts of the training and checking that are not related to the operator or to the operator’s SOPs.
PERFORMANCE AND MASS AND BALANCE APPLICATIONS
(a) General
Performance and mass and balance applications should be based on existing published data found in the AFM or performance manual, and should account for the applicable CAT.POL performance requirements. The applications may use algorithms or data spreadsheets to determine results. They may have the capability to interpolate within the information contained in the published data for the particular aircraft but they should not extrapolate beyond it.
To protect against intentional and unintentional modifications, the integrity of the database files related to performance and to mass and balance (the performance database, airport database, etc.) should be checked by the program before performing any calculations. This check can be run once at the start-up of the application.
Each software version should be identified by a unique version number. The compatibility between specific modules of a performance or mass and balance software application and the specific software revisions installed on a specific host (e.g. model of computer) should be ensured. The performance and mass and balance applications should record each computation performed (inputs and outputs) and the operator should have procedures in place to retain this information for at least 3 months.
The operator should ensure that aircraft performance or mass and balance data provided by the application is correct compared with the data derived from the AFM (e.g. for take-off and landing performance data) or from other reference data sources (e.g. mass and balance manuals or databases, in-flight performance manuals or databases) under a representative cross-check of conditions (e.g. for take-off and landing performance applications: take-off and landing performance data on dry, wet, and contaminated runways, with different wind conditions and aerodrome pressure altitudes, etc.).
The operator should establish procedures to define any new roles that the flight crew and, if applicable, the flight dispatcher, may have in creating, reviewing, and using performance calculations supported by EFB systems. In particular, the procedures should address cases where discrepancies are identified by the flight crew.
(b) Testing
The demonstration of the compliance of a performance or mass and balance application should include evidence of the software testing activities performed with the software version candidate for operational use.
The testing can be performed by either the operator or a third party, as long as the testing process is documented and the responsibilities are identified.
The testing activities should include human–machine interface (HMI) testing, reliability testing, and accuracy testing.
HMI testing should demonstrate that the application is not prone to error and that calculation errors can be detected by the flight crew with the proposed procedures. The testing should demonstrate that the applicable HMI guidelines are followed and that the HMI is implemented as specified by the application developer and in paragraph (f).
Reliability testing should show that the application in its operating environment (operating system (OS) and hardware included) is stable and deterministic, i.e. identical answers are generated each time the process is entered with identical parameters.
Accuracy testing should demonstrate that the aircraft performance or mass and balance computations provided by the application are correct in comparison with data derived from the AFM or other reference data sources, under a representative cross section of conditions (e.g. for take-off and landing performance applications: runway state and slope, different wind conditions and pressure altitudes, various aircraft configurations including failures with a performance impact, etc.).
The demonstration should include a sufficient number of comparison results from representative calculations throughout the entire operating envelope of the aircraft, considering corner points, routine and break points.
Any difference compared to the reference data that is judged significant should be examined and explained. When differences are due to more conservative calculations or reduced margins that were purposely built into the approved data, this approach should be clearly mentioned. Compliance with the applicable certification and operational rules needs to be demonstrated in any case.
The testing method should be described. The testing may be automated when all the required data is available in an appropriate electronic format, but in addition to performing thorough monitoring of the correct functioning and design of the testing tools and procedures, operators are strongly suggested to perform additional manual verification. It could be based on a few scenarios for each chart or table of the reference data, including both operationally representative scenarios and ‘corner-case’ scenarios.
The testing of a software revision should, in addition, include non-regression testing and testing of any fix or change.
Furthermore, an operator should perform tests related to its customisation of the applications and to any element pertinent to its operation that was not covered at an earlier stage (e.g. airport database verification).
(c) Procedures
Specific care is needed regarding the flight crew procedures concerning take-off and landing performance or mass and balance applications. The flight crew procedures should ensure that:
(1) calculations are performed independently by each flight crew member before data outputs are accepted for use;
(2) a formal cross-check is made before data outputs are accepted for use; such cross-checks should utilise the independent calculations described above, together with the output of the same data from other sources on the aircraft;
(3) a gross-error check is performed before data outputs are accepted for use; such gross-error checks may use either a ‘rule of thumb’ or the output of the same data from other sources on the aircraft; and
(4) in the event of a loss of functionality of an EFB through either the loss of a single application, or the failure of the device hosting the application, an equivalent level of safety can be maintained; consistency with the EFB risk assessment assumptions should be confirmed.
(d) Training
The training should emphasise the importance of executing all take-off and landing performance or mass and balance calculations in accordance with the SOPs to assure fully independent calculations.
Furthermore, due to optimisations included at various levels in performance applications, flight crew members may be confronted with new procedures and different aircraft behaviour (e.g. the use of multiple flap settings for take-off). The training should be designed and provided accordingly.
Where an application allows the computing of both dispatch results (from regulatory or factored calculations) and other results, the training should highlight the specificities of those results. Depending on the representativeness of the calculations, flight crew members should be trained on any operational margins that might be required.
The training should also address the identification and the review of default values, if any, and assumptions about the aircraft status or environmental conditions made by the application.
(e) Specific considerations for mass and balance applications
In addition to the figures, a diagram displaying the mass and its associated centre-of-gravity (CG) position should be provided.
(f) Human-factors-specific considerations
Input and output data (i.e. results) shall be clearly separated from each other. All the information necessary for a given calculation task should be presented together or be easily accessible.
All input and output data should include correct and unambiguous terms (names), units of measurement (e.g. kg or lb), and, when applicable, an index system and a CG-position declaration (e.g. Arm/%MAC). The units should match the ones from the other flight-crew-compartment sources for the same kind of data.
Airspeeds should be provided in a form that is directly useable in the flight crew compartment, unless the unit clearly indicates otherwise (e.g. Knots Calibrated Air Speed (KCAS)). Any difference between the type of airspeed provided by the EFB application and the type provided by the aircraft flight manual (AFM) or flight crew operating manual (FCOM) performance charts should be mentioned in the flight crew guides and training material.
If the landing performance application allows the computation of both dispatch (regulatory, factored) and other results (e.g. in-flight or unfactored), flight crew members should be made aware of the computation mode used.
(1) Inputs:
The application should allow users to clearly distinguish user entries from default values or entries imported from other aircraft systems.
Performance applications should enable the flight crew to check whether a certain obstacle is included in the performance calculations and/or to include new or revised obstacle information in the performance calculations.
(2) Outputs:
All critical assumptions for performance calculations (e.g. the 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 the flight crew members as similar information would be on a tabular chart.
All output data should be available in numbers.
The application should indicate when a set of entries results in an unachievable operation (for instance, a negative stopping margin) with a specific message or colour scheme. This should be done in accordance with the relevant provisions on messages and the use of colours.
In order to allow a smooth workflow and to prevent data entry errors, the layout of the calculation outputs should be such that it is consistent with the data entry interface of the aircraft applications in which the calculation outputs are used (e.g. flight management systems).
(3) Modifications:
The user should be able to easily modify performance calculations, especially when making last minute changes.
The results of calculations and any outdated input fields should be deleted whenever:
(i) modifications are entered;
(ii) the EFB is shut down or the performance application is closed; or
(iii) the EFB or the performance application has been in a standby or ‘background’ mode for too long, i.e. such that it is likely that when it is used again, the inputs or outputs will be outdated.
AIRPORT MOVING MAP DISPLAY (AMMD) APPLICATION WITH OWN-SHIP POSITION
(a) General
An AMMD application should not be used as the primary means of navigation for taxiing and should be only used in conjunction with other materials and procedures identified within the operating concept (see paragraph e)).
When an AMMD is in use, the primary means of navigation for taxiing remains the use of normal procedures and direct visual observation out of the flight-crew-compartment window.
Thus, as recognised in ETSO-C165a, an AMMD application with a display of own-ship position is considered to have a minor safety effect for malfunctions that cause the incorrect depiction of aircraft position (own-ship), and the failure condition for the loss of function is classified as ‘no safety effect’.
(b) Minimum requirements
AMMD software that complies with European Technical Standard Order ETSO-C165a is considered to be acceptable.
In addition, the system should provide the means to display the revision number of the software installed.
To achieve the total system accuracy requirements of ETSO-C165a, an airworthiness-approved sensor using the global positioning system (GPS) in combination with a medium-accuracy database compliant with EUROCAE ED-99C/RTCA DO-272C, ‘User Requirements for Aerodrome Mapping Information,’ (or later revisions) is considered one acceptable means.
Alternatively, the use of non-certified commercial off-the-shelf (COTS) position sources may be acceptable in accordance with AMC7 SPA.EFB.100(b)(3).
(c) Data provided by the AMMD software application developer
The operator should ensure that the AMMD software application developer provides the appropriate data including:
(1) installation instructions or the equivalent as per ETSO-C165a Section 2.2 that address:
(i) the identification of each specific EFB system computing platform (including the hardware platform and the operating system version) with which this AMMD software application and database was demonstrated to be compatible;
(ii) the installation procedures and limitations for each applicable platform (e.g. required memory resources, configuration of Global Navigation Satellite System (GNSS) antenna position);
(iii) the interface description data including the requirements for external sensors providing data inputs; and
(iv) means to verify that the AMMD has been installed correctly and is functioning properly.
(2) any AMMD limitations, and known installation, operational, functional, or performance issues of the AMMD.
(d) AMMD software installation in the EFB
The operator should review the documents and the data provided by the AMMD developer, and ensure that the installation requirements of the AMMD software in the specific EFB platform and aircraft are addressed. Operators are required to perform any verification activities proposed by the AMMD software application developer, as well as identify and perform any additional integration activities that need to be completed; and
(e) Operational procedures
Changes to operational procedures of the aircraft (e.g. flight crew procedures) should be documented in the operations manual or user’s guide as appropriate. In particular, the documentation should highlight that the AMMD is only designed to assist flight crew members in orienting themselves on the airport surface so as to improve the flight crew members’ positional awareness during taxiing, and that it is not to be used as the basis for ground manoeuvring.
(f) Training requirements
The operator may use flight crew procedures to mitigate some hazards. These should include limitations on the use of the AMMD function or application. As the AMMD could be a compelling display and the procedural restrictions are a key component of the mitigation, training should be provided in support of an AMMD.
All mitigation means that rely on flight crew procedures should be included in the flight crew training. Details of the AMMD training should be included in the operator’s overall EFB training.
USE OF COMMERCIAL OFF-THE-SHELF (COTS) POSITION SOURCE
COTS positions sources may be used for AMMD EFB applications and for EFB applications displaying the own-ship position in-flight when the following considerations are complied with:
(a) Characterisation of the receiver:
The position should originate from an airworthiness approved GNSS receiver, or from a COTS GNSS receiver fully characterised in terms of technical specifications and featuring an adequate number of channels (12 or more).
The EFB application should, in addition to position and velocity data, receive a sufficient number of parameters related to the fix quality and integrity to allow compliance with the accuracy requirements (e.g. the number of satellites and constellation geometry parameters such as dilution of position (DOP), 2D/3D fix).
(b) Installation aspects:
If the COTS position sources are stand-alone PEDs, they should be treated as C-PEDs and their installation and use should follow the requirements of CAT.GEN.MPA.140.
If an external COTS position source transmits wirelessly, cyber security aspects have to be considered.
Non-certified securing systems should be assessed according to paragraph (h) of AMC1 CAT.GEN.MPA.141(a).
(c) Practical evaluation:
As variables can be introduced by the placement of the antennas in the aircraft and the characteristics of the aircraft itself (e.g. heated and/or shielded windshield effects), the tests have to take place on the type of aircraft in which the EFB will be operated, with the antenna positioned at the location to be used in service.
(1) COTS used as a position source for AMMD
The test installation should record the data provided by the COTS position source to the AMMD application.
The analysis should use the recorded parameters to demonstrate that the AMMD requirements are satisfactorily complied with in terms of the total system accuracy (taking into account database errors, latency effects, display errors, and uncompensated antenna offsets) within 50 metres (95 %). The availability should be sufficient to prevent distraction or increased workload due to frequent loss of position.
When demonstrating compliance with the following requirements of DO-257A, the behaviour of the AMMD system should be evaluated in practice:
(i) indication of degraded position accuracy within 1 second (Section 2.2.4 (22)); and
(ii) indication of a loss of positioning data within 5 seconds (Section 2.2.4 (23)); conditions to consider are both a loss of the GNSS satellite view (e.g. antenna failure) and a loss of communication between the receiver and the EFB.
(2) COTS position source used for applications displaying own-ship position in flight:
Flight trials should demonstrate that the COTS GNSS availability is sufficient to prevent distraction or increased workload due to frequent loss of position.
CHART APPLICATIONS
The navigation charts that are depicted should contain the information necessary, in an appropriate form, to perform the operation safely. Consideration should be given to the size, resolution and position of the display to ensure legibility whilst retaining the ability to review all the information required to maintain adequate situational awareness.
In the case of chart application displaying own-ship position in-flight, AMC10 SPA.EFB.100(b)(3) is applicable.
IN-FLIGHT WEATHER APPLICATIONS
(a) General
An in-flight weather (IFW) application is an EFB function or application enabling the flight crew to access meteorological information. It is designed to increase situational awareness and to support the flight crew when making strategic decisions.
An IFW function or application may be used to access both information required to be on board (e.g. World Area Forecast Centre (WAFC) data) and supplemental weather information.
The use of IFW applications should be non-safety-critical and not necessary for the performance of the flight. In order for it to be non-safety-critical, IFW data should not be used to support tactical decisions and/or as a substitute for certified aircraft systems (e.g. weather radar).
Any current information from the meteorological documentation required to be carried on board or from aircraft primary systems should always prevail over the information from an IFW application.
The displayed meteorological information may be forecasted and/or observed, and may 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.
The meteorological information provided to the flight crew should be, as far as possible, consistent with the information available to users of ground-based aviation meteorological information (e.g. operations control centre (OCC) staff, flight dispatchers, etc.) in order to establish common situational awareness and to facilitate collaborative decision-making.
(b) Display
Meteorological information should be presented to the flight crew in a format that is appropriate to the content of the information; coloured graphical depiction is encouraged whenever practicable.
The IFW display should enable the flight crew to:
(1) distinguish between observed and forecasted weather data;
(2) identify the currency or age and validity time of the weather data;
(3) access the interpretation of the weather data (e.g. the legend);
(4) obtain positive and clear indications of any missing information or data and determine areas of uncertainty when making decisions to avoid hazardous weather; and
(5) be aware of the status of the data link that enables the necessary IFW data exchanges.
Meteorological information in IFW applications may be displayed, for example, as an overlay over navigation charts, over geographical maps, or it may be a stand-alone weather depiction (e.g. radar plots, satellite images, etc.).
If meteorological information is overlaid on navigation charts, special consideration should be given to HMI issues in order to avoid adverse effects on the basic chart functions.
In case of display of own-ship position in flight, AMC10 SPA.EFB.100(b)(3) is applicable.
The meteorological information may require reformatting to accommodate for example the display size or the depiction technology. However, any reformatting of the meteorological information should preserve both the geo-location and intensity of the meteorological conditions regardless of projection, scaling, or any other types of processing.
(c) Training and procedures
The operator should establish procedures for the use of an IFW application.
The operator should provide adequate training to the flight crew members before using an IFW application. This training should address:
(1) limitations of the use of an IFW application:
(i) acceptable use (strategic planning only);
(ii) information required to be on board; and
(iii) latency of observed weather information and the hazards associated with utilisation of old information;
(2) information on the display of weather data:
(i) type of displayed information (forecasted, observed);
(ii) symbology (symbols, colours); and
(iii) interpretation of meteorological information;
(3) identification of failures and malfunctions (e.g. incomplete uplinks, data-link failures, missing info);
(4) human factors issues:
(i) avoiding fixation; and
(ii) managing workload.
APPLICATIONS DISPLAYING OWN-SHIP POSITION IN FLIGHT
(a) Limitations
The display of own-ship position in flight as an overlay to other EFB applications should not be used as a primary source of information to fly or navigate the aircraft.
Except on VFR flights over routes navigated by reference to visual landmark, the display of the own-ship symbol is allowed only in aircraft having a certified navigation display (moving map).
In the specific case of IFW applications, the display of own-ship on such applications is restricted to aircraft equipped with a weather radar.
(b) Position source and accuracy
The display of own-ship position may be based on a certified GNSS or GNSS-based (e.g. GPS/IRS) position from certified aircraft equipment or on a portable COTS position source in accordance with AMC7 SPA.EFB.100(b)(3).
The own-ship symbol should be removed and the flight crew notified if:
(1) the position source indicates a degraded accuracy. The threshold to consider that the accuracy is degraded should be commensurate with the navigation performance required for the current phase of flight and should not exceed 200 m when the own-ship is displayed above a terminal chart (i.e. SID, STAR, or instrument approach) or a depiction of a terminal procedure;
(2) the position data is reported as invalid by the GNSS receiver; or
(3) the position data is not received for 5 seconds.
(c) Charting data considerations
If the map involves raster images that have been stitched together into a larger single map, it should be demonstrated that the stitching process does not introduce distortion or map errors that would not correlate properly with a GNSS-based own-ship symbol.
(d) Human machine interface (HMI)
(1) Interface
The flight crew should be able to unambiguously differentiate the EFB function from avionics functions available in the cockpit, and in particular with the navigation display.
A sufficiently legible text label ‘AIRCRAFT POSITION NOT TO BE USED FOR NAVIGATION’ or equivalent should be continuously displayed by the application if the own-ship position depiction is visible in the current display area over a terminal chart (i.e. SID, STAR, or instrument approach) or a depiction of a terminal procedure.
(2) Display of own-ship symbol
The own-ship symbol should be different from the ones used by certified aircraft systems intended for primary navigation.
If directional data is available, the own-ship symbol may indicate directionality. If direction is not available, the own-ship symbol should not imply directionality.
The colour coding should not be inconsistent with the manufacturer philosophy.
(3) Data displayed
The current map orientation should be clearly, continuously and unambiguously indicated (e.g., Track-up vs North-up).
If the software supports more than one directional orientation for the own-ship symbol (e.g., Track-up vs North-up), the current own-ship symbol orientation should be indicated.
The chart display in track-up mode should not create usability or readability issues. In particular, chart data should not be rotated in a manner that affects readability.
The application zoom levels should be appropriate for the function and content being displayed and in the context of providing supplemental position awareness.
The pilot should be able to obtain information about the operational status of the own-ship function (e.g. active, deactivated, degraded).
During IFR, day-VFR without visual references or night VFR flight, the following parameters’ values should not be displayed:
(i) Track/heading;
(ii) Estimated time of arrival (ETA);
(iii) Altitude;
(iv) Geographical coordinates of the current location of the aircraft; and
(v) Aircraft speed.
(4) Controls
If a panning and/or range selection function is available, the EFB application should provide a clear and simple method to return to an own-ship-oriented display.
A means to disable the display of the own-ship position should be provided to the flight crew.
(e) Training and procedures
The procedures and training should emphasise the fact that the display of own-ship position on charts or IFW EFB applications should not be used as a primary source of information to fly or navigate the aircraft or as a primary source of weather information.
(1) Procedures:
The following considerations should be addressed in the procedures for the use of charts or IFW EFB application displaying the own-ship position in flight by the flight crew:
(i) Intended use of the display of own-ship position in flight on charts or IFW EFB applications;
(ii) Inclusion of the EFB into the regular scan of flight deck systems indications. In particular, systematic cross-check with avionics before being used, whatever the position source; and
(iii) Actions to be taken in case of identification of a discrepancy between the EFB and avionics.
(2) Training:
Crew members should be trained on the procedures for the use of the application, including the regular cross-check with avionics and the action in case of discrepancy.
EFB POLICY AND PROCEDURES MANUAL
The items that follow are the typical contents of an EFB policy and procedures manual that can be part of the operations manual. The proposed outline is very extensive. It may be adapted to the specific EFB system and to the size and complexity of the operations in which the operator is involved.
(a) Revision history;
(b) List of effective pages or paragraphs;
(c) Table of contents;
(d) Introduction:
(1) Glossary of terms and acronyms;
(2) EFB general philosophy, environment, and dataflow;
(3) EFB system architecture;
(4) Limitations of the EFB system;
(5) Hardware description;
(6) Operating system description;
(7) Detailed presentation of the EFB applications;
(8) EFB application customisation;
(9) Data management:
(i) data administration;
(ii) organisation and workflows;
(iii) data loading;
(iv) data revision mechanisms;
(v) approval workflow;
(vi) data publishing and dispatch;
(vii) customisation;
(viii) how to manage operator-specific documents;
(ix) airport data management;
(x) aircraft fleet definition;
(10) Data authoring:
(i) navigation and customisation;
(e) Hardware and operating system control and configuration:
(1) Purpose and scope;
(2) Description of the following processes:
(i) hardware configuration and part number control;
(ii) operating system configuration and control;
(iii) accessibility control;
(iv) hardware maintenance;
(v) operating system updating;
(3) Responsibilities and accountability;
(4) Records and filing;
(5) Documentary references;
(f) Software application control and configuration:
(1) Purpose and scope;
(2) Description of the following processes:
(i) version control;
(ii) software configuration management;
(iii) application updating process;
(3) Responsibilities and accountability;
(4) Records and filing;
(5) Documentary references;
(g) Flight crew:
(1) Training;
(2) Operating procedures (normal, abnormal, and emergency);
(h) Maintenance considerations;
(i) EFB security policy:
(1) Security solutions and procedures.
FLIGHT CREW TRAINING
The following might be a typical training syllabus, provided that it does not contradict the operational suitability data established in accordance with Regulation (EU) No 748/2012.
(a) Ground-based training:
(1) System architecture overview;
(2) Display unit features and use;
(3) Limitations of the system;
(4) Restrictions on the use of the system:
(i) phases of the flight;
(ii) alternate procedures (e.g. MEL);
(5) Applications as installed;
(6) Use of each application;
(7) Restrictions on the use of each application:
(i) phases of the flight;
(ii) alternate procedures (e.g. MEL);
(8) Data input;
(9) Cross-checking of data inputs and outputs;
(10) Use of data outputs;
(11) Alternate procedures (e.g. MEL);
(b) Flight training:
(1) Practical use of the display unit;
(2) Display unit controls;
(3) Data input devices;
(4) Selection of applications;
(5) Practical use of applications;
(6) Human factors considerations, including CRM;
(7) Situational awareness;
(8) Avoidance of fixation;
(9) Cross-checking of data inputs and outputs;
(10) Practical integration of EFB procedures into SOPs;
(11) Actions following the failure of component(s) of the EFB, including cases of battery smoke or fire; and
(12) Management of conflicting information.
SECURITY
Examples of typical safety and security defences are contained in the following non-exhaustive list:
(a) Individual system firewalls;
(b) The clustering of systems with similar safety standards into domains;
(c) Data encryption and authentication;
(d) Virus scans;
(e) Keeping the OS up to date;
(f) Initiating air–ground connections only when required and always from the aircraft;
(g) ‘Whitelists’ for allowed internet domains;
(h) Virtual private networks (VPNs);
(i) Granting of access rights on a need-to-have basis;
(j) Troubleshooting procedures that consider security threats as potential root causes of EFB misbehaviour, and provide for responses to be developed to prevent future successful attacks when relevant;
(k) Virtualisation; and
(l) Forensic tools and procedures.
IN-FLIGHT WEATHER (IFW) APPLICATIONS
‘Reliable sources’ of data used by IFW applications are the organisations evaluated by the operator as being able to provide an appropriate level of data assurance in terms of accuracy and integrity. It is recommended that the following aspects be considered during that evaluation:
(a) The organisation should have a quality assurance system in place that covers the data source selection, acquisition/import, processing, validity period check, and the distribution phase;
(b) Any meteorological product provided by the organisation that is within the scope of the meteorological information included in the flight documentation as defined in MET.TR.215(e) (Annex V (Definitions of terms used in Annexes II to XIII) to Commission Implementing Regulation (EU) 2016/137789 Commission Implementing Regulation (EU) 2016/1377 of 4 August 2016 laying down common requirements for service providers and the oversight in air traffic management/air navigation services and other air traffic management network functions, repealing Regulation (EC) No 482/2008, Implementing Regulations (EU) No 1034/2011 and (EU) No 1035/2011 and amending Regulation (EU) No 677/2011 (OJ L 226, 19.8.2016, p. 1).) should originate only from authoritative sources or certified providers and should not be transformed or altered, except for the purpose of packaging the data in the correct format. The organisation’s process should provide assurance that the integrity of those products is preserved in the data for use by the IFW application.
USE OF COMMERCIAL OFF-THE-SHELF (COTS) POSITION SOURCE – PRACTICAL EVALUATION
The tests should consist of a statistically relevant sample of taxiing. It is recommended to include taxiing at airports that are representative of the more complex airports typically accessed by the operator. Taxiing segment samples should include data that is derived from runways and taxiways, and should include numerous turns, in particular of 90 degrees or more, and segments in straight lines at the maximum speed at which the own-ship symbol is displayed. Taxiing segment samples should include parts in areas of high buildings such as terminals. The analysis should include at least 25 inbound and/or outbound taxiing segments between the parking location and the runway.
During the tests, any unusual events (such as observing the own-ship symbol in a location on the map that is notably offset compared to the actual position, the own-ship symbol changing to non-directional when the aircraft is moving, and times when the own-ship symbol disappears from the map display) should be noted. For the test, the pilot should be instructed to diligently taxi on the centre line.
APPLICATIONS DISPLAYING OWN-SHIP POSITION IN FLIGHT
The depiction of a circle around the EFB own-ship symbol may be used to differentiate it from the avionics one.