MOC VTOL.2620 Electronic Aircraft Flight Manual

1.      INTRODUCTION AND SCOPE

This MOC presents guidelines for obtaining approval of an electronic version of an Aircraft Flight Manual (eAFM). These guidelines also apply to eAFM appendices and supplements. The guidelines are applicable to eAFM applications running on hardware platforms which may or may not be included in the aircraft type design definition.

(a)      These guidelines cover:

(1)     The definitions of the eAFM and its constituents, as well as its relationship with the EFB world;

(2)     The expected process for airworthiness approval of the eAFM;

(3)     The acceptable means to ensure:

(i)      completeness and integrity of the eAFM, as well as the means for ensuring control of its configuration and of the information thereby provided;

(ii)     management of supplemental information regarding specific aircraft configurations and removable kits;

(iii)     approval of post-TC eAFM revisions, either stand alone or design change related, including those done by third parties and those resulting from continuing airworthiness processes.

(b)     These guidelines do not cover:

(1)     Systems that provide input to other aircraft systems or equipment;

(2)     Supplementary software or software functions used to prepare documentation suitable for use in the operation of the aircraft under the applicable operating rules (e.g. airport analysis software).

(c)      Similarly to a paper AFM, eAFM software application is not certified as part of the aircraft type design, however it is approved by the Agency for showing compliance with VTOL.2620 and becomes part of the type certificate.

(d)     The operational rules (Commission Regulation (EU) No 965/2012 and subsequent amendments) include provisions for the use of an eAFM. However, from an airworthiness approval standpoint, the showing of compliance of the aircraft eAFM with the TC basis requirements should be based on this MOC.

(e)     When the eAFM is hosted and used in flight on non-installed equipment (not part of the type design definition), such as on a tablet device, it is considered to be an Electronic Flight Bag (EFB) application. In this case the operational rules apply, which address the use of EFB, including the operational risk assessment, paperless operations, environmental testing, administration, Human-Machine Interface and Human Factors considerations, and pilot procedures and training.

2.      Definitions

The primary purpose of the AFM required by VTOL.2620 is to provide an authoritative source of information necessary for the safe operation of the aircraft. In this aim, it is based in the first place on source technical data files from which all required AFM information should be gathered, classified, organized, and prioritized. These data files need to be processed by a specific software application to allow interactive display of the information in a given format and structure. The eAFM software application may run on different kinds of host platforms with various hardware and operating systems.

The following definitions apply:

(a)      Electronic AFM (eAFM): Set of data files and a software application used to provide interactive display of AFM information on an authorised host platform.

(b)     Software Application: The software program(s), installation information and operating guide to be used by the end user in conjunction with the data files to display the eAFM information.

(c)      Host Platform: The hardware and basic software (e.g. Operative System (OS), input/output software) environment that enables the operation of the software application to input, process and output the eAFM information to the end user.

(d)     Authorised host platform configuration: Host platform configuration with characteristics (e.g. input/output hardware characteristics, Operating System version, Central Processing Unit (CPU) type, CPU frequency, memory) for which the eAFM performance and integrity are guaranteed.

Note: Particular cases of authorised host platform configuration are the “worst case authorised host platform configurations” that correspond to the configurations with minimum characteristics ensuring the eAFM performance and integrity.

3.      eAFM scope of approval and deliverable data package

The approved constituent elements of an eAFM are the data files and the software application(s). The host platform is not part of the approved eAFM. If it is not part of the type design definition (e.g. in the case of non-installed equipment such as portable COTS equipment), the list of host platform configuration characteristics and their authorised range will be identified as conditions for the eAFM approval.

Therefore, the following information should be clearly identified and made available with each aircraft:

(a)      The eAFM data files applicable to that aircraft, i.e. name, format, version, and date.

(b)     The eAFM software application(s), i.e. name, version, part or build number, installation information (including verification procedure, see Section 5(b)(3) in this MOC) and operating guide.

(c)      If the host platform is non-installed equipment (not part of the type design definition), the list of authorised host platform configuration characteristics and the range in which those characteristics may evolve while ensuring the correct performance of the eAFM.

4.      Compliance demonstration

(a)      The following eAFM aspects should be addressed in the demonstration of compliance with VTOL.2620:

(1)     The technical content of the approved AFM information (e.g. Limitations, Normal and Emergency procedures, Performance data, etc.);

(2)     The structure of this technical content, i.e. the way the different sections, subsections and single information of the eAFM are ordered and structured in relation with each other;

(3)     The eAFM information format, i.e. the way the technical content and structure of the eAFM are displayed.

(b)     The software application(s) should ensure at any time segregation and clear distinction of the approved data from non-approved ones, in particular when interactive functions of the software are in use. The software should always show if any information is approved (by indication of the approval status and approving organisation/authority) or belongs to the non-approved part of the AFM.

(c)      Identification of the approval status of the eAFM (data file version, SW application version, etc.) should be made readily available to the end user via a dedicated function or permanently displayed. The eAFM should be under configuration management control and a unique identifier covering all the eAFM constituents should be available. 

(d)     Practical access to, and readability and usability of, the eAFM information on ground, in flight, and during any foreseeable normal and emergency operating condition should be also demonstrated.

5.      Software considerations

(a)      The integrity and reliability of the eAFM software application(s) running on an authorised host platform should be commensurate with the safety objectives defined for their identified failure conditions.

(b)     Software running on non-installed equipment:

(1)     If the software application is intended to be installed on non-installed equipment, not part of the type design definition, such as Commercial Off-the-Shelf (COTS) platforms and possibly under control by the operator, the lack of development assurance of the platform should be compensated for by at least the following:

(iv)     Development assurance activities at application level; and

(v)     Verification at eAFM end user level (operator).

(2)     A software development assurance process for the eAFM software application(s) should be defined and implemented. It should include in particular extensive[9] verification of the eAFM functionality, including robustness test cases, in a repeatable and standardised manner and for the worst-case authorised platform configurations. This could be achieved by means of development assurance processes (e.g. DO‑178()/ED‑12(), DO-330/ED-215...) or other appropriate means to be agreed by the Agency.

(3)     An additional verification procedure should be developed and provided to end users, as part of the eAFM installation information, for them to ensure adequate verification of the eAFM functionality on their final host platform configuration(s). It should also provide information on how to ensure the absence of regression in case of new or updated host platforms (e.g. Operating System update) or when new software application versions are released.

(c)      eAFM data files: The integrity of the eAFM information should be ensured, e.g. by means of CRC protection of the data files.

(d)     Identification of the authorized host platform characteristics

(1)     The host platform will not be part of the Agency approved eAFM.

(2)     The host platform can consist of COTS equipment, without software or hardware qualification, whose technological and performance features as available on the market may change very rapidly. Therefore, the specifications of the host platform configuration characteristics for which the eAFM performance and integrity are guaranteed should be provided.

(3)     The eAFM host platform may be an EFB (as defined in the Air Operations Regulation).

(e)     Software running on installed equipment: If the eAFM is intended to be hosted in installed equipment (part of the type design definition), the host platform characteristics are fully defined (at the time of its certification); therefore the development assurance at application level can be performed on the final target platform alleviating the need for verification at end user level.

6.      eAFM supplements

The eAFM may contain supplements or may propose to embed them in the basic eAFM structure.

In the latter case, the eAFM software application should have a safeguarded feature for selection and de-selection of eAFM for kits, optional equipment, or supplemental information. For this purpose, it should be demonstrated that:

(a)      The selection of eAFM supplements for kits is restricted by design only to the people/organizations holding proper rights and responsibilities for making such changes;

(b)     The risk of inadvertent changes to the aircraft configuration is properly mitigated, e.g. by means of disclaimers and warning messages displayed on the screen and/or confirmation actions to be performed in order to implement the change;

(c)      The selection of eAFM supplements for kits is always readily accessible from any view of the eAFM;

(d)     Simultaneous selection of eAFM supplements for incompatible kits is not possible;

(e)     Information regarding eAFM supplements for kits whose operation is optional is properly tagged as “if operated”;

(f)      Information regarding eAFM supplements for kits that may be removable is properly tagged as “if installed”;

(g)      The eAFM provides a log of all selectable supplements for kits or supplemental information.

7.      Performance computation

(a)      Software assurance

(1)     If the eAFM includes a performance computation function, by which the flight crew can calculate and display the aircraft performance both during the flight preparation and in flight, the following additional considerations apply.

(i)      The applicant should perform a safety assessment of the performance computation function in order todefine the safety objectives as prescribed by VTOL.2510. A software development assurance process should then be defined and implemented in accordance with AMC 20-115()

(ii)     Considering the nature of an eAFM software application, certain adaptations to the DO-178()/ED-12() objectives may be necessary. The rationale for any objective alleviation should be documented. It should be demonstrated that any objective removal can only cause at worst eAFM availability problems and cannot lead to data integrity problems (i.e. production of erroneous data).

(iii)     The following adaptations to ED-12C (or later revisions) objectives are provided as examples:

(b)     Database Assurance: Databases used for performance calculation should be produced using standard industry processes such as the provisions of DO-178()/DE-12() for Parameter Data Item verification, configuration and change controls or the processes of.DO-200()/ED-76(), as applicable, to a level commensurate with the failure effects identified in the safety assessment.

(c)      Software Usage Aspects: The applicant should substantiate that the eAFM performance computation function is designed to:

(1)     Provide a generated output containing all the information required to be in the AFM by VTOL.2620. This includes all relevant information (e.g. variables used for a specific condition) to determine operating condition and applicability of the generated output.

(2)     Provide equivalent or conservative results to that obtained by performance charts otherwise approved (e.g. in paper/pdf format) for the AFM.

(3)     Preclude calculations that would generate results identified as EASA approved by:

(iv)     Extrapolating data beyond computational bounds agreed to by the Agency and the applicant; or

(v)     Using unapproved flight test analysis or AFM expansion methods.

(4)     Provide a satisfactory level of transparency (e.g. understanding of performance relations and limitations).

(d)     Interface Aspects: The applicant should substantiate that the eAFM performance calculation function is designed to minimise mistakes or misunderstanding by a trained user during data input and interpretation of output. For this purpose, guidance on Air Operations Regulation for Human Machine Interface and Human Factors aspects of Electronic Flight Bags, such as AMC1 SPA.EFB.100(b)(2) and paragraph (f) of AMC5 SPA.EFB.100(b)(3), may be considered.

8.      eAFM Approval Process

(a)      The Agency will approve the initial version of the “envelope” eAFM, i.e. the full set of all approved AFM content. Any subsequent revision will be also approved, either directly by the Agency or by means of a DOA privilege.

(b)      TC holders may have the privilege, under the Authority of their DOA/POA, to define the content of each individual aircraft eAFM (customised eAFM), by selecting the appropriate approved parts from the envelope eAFM, according to the known configuration of this individual aircraft, and, if needed, the particular requests of the Authority of the country of registration of the aircraft, and distribute this eAFM to the operator. 

9.      eAFM Customization

Customised eAFM may be built for specific operators’ configurations and managed under the DOA/POA responsibility. With this regard, the following apply:

(a)      If the approved eAFM is intended to be the one applicable to all fleet and incorporating all kits, clear instructions on how to customize this eAFM application(s) should be available for operators.

(b)     As some eAFM information (e.g. limitation, procedures, etc.) may be applicable to a single or limited number of aircraft only, it should be specified how this information will be managed and conveyed into the customized eAFM, clarifying also in which cases such information may take precedence and replace the one of the basic eAFM.

10.     Printed copies and excerpts of the eAFM

(a)      Printed copies or excerpts of the eAFM could lead to use incorrect or obsolete data, which could endanger the conduct of the flight. Therefore, excerpts or copies under any format (printed, .pdf, .jpg, .xps, .png, etc) of any part of or of the entire eAFM directly from the software application(s) should be either not allowed or considered and marked as uncontrolled. In particular, if permitted, the extraction of information for building up operational documentation should not impair or corrupt the technical content, the structure and the presentation format of the approved eAFM.

(b)     Moreover, the following objectives apply:

(1)     The segregation of the data, as well as separation of the approved from unapproved data should be maintained in the pdf or printed copy.

(2)     The pdf or printed copy should clearly identify the issue or version of the eAFM and the specific aircraft configuration to which it refers.

11.     Design organization processes

It is recommended that the applicant’s approved design organization ensures that it identifies and implements all needed processes specific to the eAFM, covering in particular aspects such as electronic authoring and distribution of the eAFM, normal revisions, third party changes (such as resulting from Supplemental Type Certificates), and urgent content or software revisions resulting from Airworthiness Directives requirements.