AMC 25.1581, Appendix 1 Computerised Aeroplane Flight Manual

• ED Decision 2020/024/R found in: CS-25 Amdt 27 - Large Aeroplanes (Jan 2023)

AMC 25.1581, Appendix 1 Computerised Aeroplane Flight Manual ED Decision 2020/024/R 1 PURPOSE This appendix presents guidelines for obtaining approval of a computerised version of an AFM that would replace or supplement parts of the conventional paper AFM. These guidelines also apply to computerised AFM appendices and supplements. The criteria provided in the main body of this AMC remain applicable except where modified by this appendix. These guidelines do not cover: a. Systems used on board the aeroplane during flight. b. Systems that provide direct input to other aeroplane systems or equipment. c. Supplementary software or software functions used to prepare documentation suitable for use in the operation of the aeroplane under the applicable operating rules (e.g. airport analysis software). 2 APPLICABILITY This appendix applies to aeroplanes eligible to be certificated to CS 25. The guidelines contained herein pertain to generating and presenting AFM performance information required by CS 25 by means of computer software. This appendix may be amended to include relevant aspects for other EASA approved information that is stored and presented through computer software. 3 DEFINITIONS a. Computerised AFM. The computerised AFM software application used in conjunction with the hardware and software environment in which it is installed to generate computerised AFM information. b. Computerised AFM Software Application. The computer programs and data, installation information and operating guide that are used in generating computerised AFM information. c. Computerised AFM Information. The information generated by the EASA approved computerised AFM in lieu of or supplementing parts of the conventional paper AFM. d. Software Environment. The additional computer programs (e.g. operating system) that provide services to the computerised AFM software application to input, process and output the information to the user. e. Hardware Environment. The equipment (e.g. terminal, printer, keyboard, math co-processor, central processing unit, etc.) that enables the operation of the software environment and the computerised AFM software application to input, process and output the information to the user. f. Commercial-Off-the-Shelf (COTS) Computer. A multi-purpose computer (e.g. a standard personal computer) that is available, or can be made available, to all potential users of the respective computerised AFM. g. Calculation. Data generation by means of combination of table-lookup or arithmetic operations. h. First Principles Calculation. A Calculation using basic parameters such as lift, drag, thrust, etc. with the equations of motion. 4 GENERAL GUIDELINES The criteria herein do not affect the status of computerised AFMs that have previously been EASA or JAA approved. When such manuals are amended in the future, the concepts of this appendix should be applied, where practicable. a. Official Reference (1) The conventional paper portion of the AFM should contain appropriate references about applicability of the EASA approved computerised AFM software application. This reference should be revised each time the EASA approved computerised AFM software application is changed (see paragraph 6.d of this appendix). (2) The AFM should contain a statement similar to the following: The computerised AFM replaces or supplements portions of the paper AFM, and is an EASA approved source for that AFM information. Any modification to the EASA approved computerised AFM software application, or subsequent alteration to the generated output, will cancel the airworthiness approval of the information, unless this change was approved by the EASA. This statement applies regardless of any approval notation printed on a generated output. b. Approved and Unapproved Information. Paragraph 25.1581 of the CS requires that the EASA approved information be segregated, identified and clearly distinguished from any unapproved information in the AFM. Therefore, the approval status of generated output should be clearly indicated on the screen and printed on each printout page of any calculated results by indication of: (1) Approved program version. (2) Approved data version, if applicable. (3) Approval status of results with respect to requirement basis of the computation (e.g. FAR/Certification Specifications (CS)). (4) Applicable certification basis, if the program is capable of generating results for more than one certification basis (e.g. FAR/Certification Specifications (CS)). (5) Date of output data generation. c. Software Usage Aspects. The applicant should substantiate that the computerised AFM is designed to: (1) Provide a generated output containing all the information required to be in the conventional paper AFM by CS 25 for the part that is replaced or supplemented by the computerised AFM. 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 direct use of a first principles calculation using certified baseline parameters (e.g. lift, drag, thrust). (3) Preclude calculations that would generate results identified as EASA approved by: (i) Extrapolating data beyond computational bounds agreed to by the Agency and the applicant; or (ii) Using unapproved flight test analysis or AFM expansion methods. (4) Provide at least the standard of transparency (e.g. understanding of performance relations and limitations) that is available from a conventional paper AFM presentation. (5) Minimise mistakes or misunderstanding by a trained user during data input and interpretation of output. 5 COMPUTERISED AEROPLANE FLIGHT MANUAL CONTENTS a. General (Reserved.) b. Limitations Section (Reserved.) c. Procedures Sections (Reserved.) d. Performance Section (1) The computerised AFM may be used to generate all of the EASA approved performance information required to be in the AFM. (2) The operating rules require operators to carry, in each transport category aeroplane, either the AFM or an operator-prepared manual that contains all of the information required to be in the AFM. The computerised AFM is not intended for use on board the aeroplane. Thus, any portions of the AFM that are provided only in computerised (i.e. electronic) form may not be used to satisfy these operating requirements. This does not preclude printing out information calculated by the EASA approved computerised AFM and subsequently using the paper printout on board the aeroplane. (3) Configuration Deviation List (CDL) and Master Minimum Equipment List (MMEL) effects on performance may be included if they are EASA approved and applications are clearly identified on the generated output. (4) Although the output from the computerised AFM should be usable without adjustment, applying corrective factors that are provided in the paper AFM may be acceptable in the following cases: (i) CDL or MMEL information. (ii) Urgent temporary EASA approved revisions made mandatory for safety reasons. (iii) Any case in which the appropriate data are unavailable from the computerised AFM and it is clear to the user that corrective factors must be applied. (iv) Supplements produced by STC applicants. (5) Supplementary performance information may be included in accordance with paragraph 4.b of this appendix (e.g. for operation on runways contaminated with standing water, slush, snow or ice). (6) The applicant may request EASA approval of supplementary computerised AFM applications (e.g. optimised runway performance). This supplementary software application will not be required by the EASA for type certification. 6 SOFTWARE INTEGRITY, DEVELOPMENT AND DOCUMENTATION REQUIREMENTS The computerised AFM consists of the AFM software application used in conjunction with the hardware and software environment in which it is installed. This paragraph provides guidelines that address the integrity, development process, and documentation requirements of the software. a. Software Integrity (1) The potential safety effect at the aeroplane level of the computation of hazardously misleading primary information such as take-off speeds, landing approach speeds, engine thrust or power, engine limit data or other related aeroplane performance data, should be assessed. This assessment should be the basis for determining the software architecture and the level of integrity of the AFM software application. The AFM software application should, as far as practicable, be protected from inadvertent, deliberate, or unauthorised alterations. For example, self‑check features could be used to provide software verification and protection against deliberate or inadvertent alteration. (2) The level of integrity established for the computerised AFM is the basis for the software development process and should be addressed in the plan for software aspects of certification (see paragraph 6.b of this appendix). (3) Each part of the EASA approved AFM software application (e.g. program, data) should bear a unique notation, a unique date, or a revision number. (4) A means to check the programs and data to avoid undetected failures should be provided (e.g. a checksum routine, tabular data to verify a check case, or provisions for a line-by-line file comparison). (5) Commercially available software, such as operating systems (e.g. MS-DOS), word-processors and spreadsheets, will not be approved by the EASA. However, this software can be used to run the computerised AFM software application or process (i.e. edit, format, manipulate, etc.) AFM data to produce approved AFM information if: (i) the applicant demonstrates that the unapproved software does not interfere with the correct functioning of the EASA approved computerised AFM software application; (ii) the applicant demonstrates that the unapproved software produces reliable results when used with the specified hardware environment and the computerised AFM software application; and (iii) the applicant specifies, in the paper AFM or a user’s guide, the title, manufacturer, and version number of such software. The version number may refer to future versions of the software (e.g. ‘Version XX and later’) if the verification check performed under paragraph 6.c(1) of this appendix is designed such that improper operation of these later software versions would be detected. b. Software Development. The integrity of the software components of the computerised AFM is achieved through the software development processes used. (1) The applicant should propose the software development process in the plan for software aspects of certification. The application should document the methods, parameters and allowable range of conditions contained in the computerised AFM. The results obtained from the computerised AFM should be shown to meet all applicable CS-25 requirements. This compliance may be shown using substantiation documentation, demonstrations, or other means mutually agreed to by the Agency and the applicant. The software development process described in AMC 20-115 (Software Considerations for Airborne Systems and Equipment Certification) is valid, in general, for developing either airborne or ground based software. It represents one acceptable approach, but not the only acceptable approach, for developing software for the computerised AFM. Some of the specific guidance provided in AMC 20-115, however, may not apply to the computerised AFM. (2) The applicant should submit a description of the computerised AFM and the plan for software aspects of certification to the Agency for review early in the certification process. This plan proposes the schedule and means by which compliance with the requirements will be achieved and the means by which certification data and supporting records will be made available to the Agency for review. c. Hardware and Software Environment. The computerised AFM software application may be EASA approved independent of the hardware and software environment in which it is installed. A common example of this would be the development of a computerised AFM software application to be run in a commercial-off-the-shelf (COTS) hardware and software environment. The applicant should provide for item (1) as follows, plus either item (2) or (3), as appropriate. (1) A mechanism, such as an installation utility function or test set, that verifies the proper functioning of the computerised AFM software application in the target software and hardware environment. The verification check should include, but not be limited to, proper functioning with hardware specified in the AFM, including input and output devices, and with resident software, including terminate-to-stay-resident or other control programs such as Microsoft Windows, and with any operating system calls made by the AFM software. (2) If the computerised AFM is intended for a COTS hardware and software environment, installation information that describes the minimum requirements, including limitations and constraints, for the software and hardware environment. (3) If the computerised AFM is intended for a specific hardware/software system, installation information that describes the specific hardware and software environment in which the computerised AFM software application must be installed. Additionally, the applicant should provide a configuration management scheme that ensures the hardware and software environment that will be used in service is identical to the environment specified in the EASA approved installation data. d. Revisions to a Computerised AFM Software Application (1) Revisions to a EASA approved computerised AFM should be submitted for evaluation and EASA approval in accordance with software development methodology established in paragraph 6.b of this appendix. A log of EASA approved AFM software application parts should be furnished by the applicant. For historical purposes, the applicant should maintain records from which the information from any approved revision level of the computerised AFM can be reproduced, unless none of the affected aeroplanes remain in operational service. (2) The applicant should submit a description of the proposed changes and an updated plan for software aspects of certification. In addition, the applicant should: (i) re-assess the software integrity level (paragraph 6.a of this appendix) of the revised computerised AFM; (ii) demonstrate that revisions do not affect any of the unrevised portions of the computerised AFM; and (iii) demonstrate that the revisions are compatible with the hardware and software environment intended for the computerised AFM software application. (3) Revisions to a computerised AFM can be made only by the TC or STC holder of that computerised AFM. The STC applicant may supplement but not revise a TC holder’s computerised AFM. (4) When revisions are incorporated, a means (e.g. document) of indicating those parts of the software that have been changed should be provided. (5) Each revised software element should be identified in the same manner as the original, with the exception of the new date or revision notation (see paragraph 6.a(3) of this appendix). e. Submittal and EASA Approval of Software (1) The applicant will be considered the responsible party for all matters pertaining to the computerised AFM software application, including submittal to the Agency and obtaining EASA approval. (2) The applicant and the Agency shall discuss and agree on the data structures and calculation models. (3) The applicant should provide any part of the hardware environment necessary for operating the computerised AFM that is not readily available to the Agency. f. Documentation Requirements. Documentation containing the following information should be provided by the applicant to the Agency. (1) Approval plan that describes the software aspects of certification, including time schedules, an outline of the desired applications, and design objectives for software and data integrity. (2) Software development plan, including the methods used to accomplish the design objectives. (3) Software descriptions, including justifications that program structures and calculation models are appropriate to their intended function. (4) Data verification document, including a description of the scope and depth of the review, analysis, and tests used to determine that the developed software and generated output accurately reflect the aeroplane performance characteristics. This description should include the purpose of each test case and the set of inputs, expected results, test environment and calculated results. (5) Operating instructions, including all information for proper use of the computerised AFM, installation instructions, and identification of the suitable hardware and software environment. (6) Software configuration reference, including a log of the approved software elements and a statement that design objectives of the approval plan and compliance with the guidelines of this appendix have been demonstrated. 7 PROVISIONS FOR EASA POST CERTIFICATION ACCESS TO COMPUTERISED AFM In the plan for software aspects of certification, the applicant should propose which components of the computerised AFM will be submitted to the EASA. In cases where the AFM software application can be installed on EASA equipment, the applicant need only provide the computerised AFM software application, which includes the installation data and operating guide. However, if the computerised AFM software application requires a hardware and software environment that is not available to the EASA, the applicant should also provide the EASA with the necessary components to access the AFM software application. [Amdt 25/2] [Amdt 25/12] [Amdt 25/26]