Software Approval Guidelines

3 /29/1 8 8110.49A Chapter 1. General Information 1. Purpose . This order guides Aircraft Certification Service (AIR) offices and designees on how to apply RTCA/DO - 178B and RTCA/DO - 178C, herein called RTCA/DO - 178B/C for approving software used in airborne computers. Both are titled “Software Considerations in Airborne Systems and Equipment Certification”. The guidelines are applicable to the approval of airborne systems and equipment and the software aspects of those systems related to type certificates (TC), supplemental type certificates (STC), amended type certificates (ATC), amended supplemental type certificates (ASTC), and technical standard order (TSO) authorizations (TSOA).

Note: R eferences to use of DO - 178C in this order include use of supplements (DO - 331, DO - 332, DO - 333) and DO - 330, as applicab le.

2. Audience . Managers and staff of the FAA Aircraft Certification Service, including any persons designated by the administrator, and organizations associated with the certification process required by Title 14 of the Code of Federal Regulations (14 CFR) .

3. Related Publications . The latest amendments of the following publications are the primary reference materials for this order: a. Code of Federal Regulations. 14 CFR p art 21, Certification Procedures for Products and Parts .

b. FAA ACs and Orders. Copies of the following ACs and orders are available from the FAA website at http://www.faa.gov/regulations_policies .

(1) AC 20 - 115, Airborne Software Development Assurance Using EUROCAE ED - 12( ) and RTCA DO - 178( ) .

(2) AC 21 - 43, Production Under 14 CFR Part 21, Subparts F, G, K, and O.

(3) AC 23.1309 - 1, System Safety Analysis and Assessment for Part 23 Airplanes.

(4) AC 25.1309 - 1, System Design and Analysis.

(5) AC 27 - 1, Certification of Normal Category Rotorcraft.

(6) AC 29 - 2, Certification of Transport Category Rotorcraft.

(7) AC 33.28 - 1, Compliance Criteria for 14 CFR 33.28, Aircraft Engines, Electrical and Electronic Engine Control Systems.

(8) AC 33.28 - 2, Guidance Material for 14 CFR 33.28, Reciprocating Engine, Electrical and Electronic Engine Control Systems.

(9) AC 33.28 - 3, Guidance Material for 14 CFR 33.28, Engine Control Systems.

1 - 1 3 /29/1 8 8110.49A (10) Order 8040.4, Safety Risk Management Policy.

(11) Order 8110.4, Type Certification Process.

c. RTCA, Inc. Documents. Copies of RTCA documents may be purchased from RTCA, Inc., 1150 18th St. NW, Suite 910, Washin gton, D.C. 20036. Alternatively, copies may be purchased on - line at http://www.rtca.org . RTCA documents referenced in this order are: (1) RTCA, Inc., document RTCA/DO - 178B, Software Considerations in Airborne Systems and E quipment Certification, dated December 1, 1992.

(2) RTCA, Inc., document RTCA/DO - 178C, Software Considerations in Airborne Systems and Equipment Certification, dated December 13, 2011.

(3) RTCA, Inc., document RTCA/DO - 248C, Supporting Information for DO - 178C and D O - 278A, dated December 13, 2011.

(4) RTCA DO - 330, Software Tool Qualification Considerations, dated December 13, 2011.

(5) RTCA DO - 331, Model - Based Development and Verification Supplement to DO - 178C and DO - 278A, dated December 13, 2011.

(6) RTCA DO - 332, Object - Oriente d Technology and Related Techniques Supplement to DO - 178C and DO - 278A, dated December 13, 2011.

(7) RTCA DO - 333, Formal Methods Supplement to DO - 178C and DO - 278A, dated December 13, 2011 .

4. Cancellation. This order cancels and supersedes FAA Order 8110.49 Chg 2 , Software Approval Guidelines, dated April 10, 2017 .

5. Explanation of Changes . FAA Order 8110.49 Chg 2, dated 4/10/17 , Chapters 5 – 16 were deleted to eliminate duplication or conflict since the topi cs previously addressed in these chapters are now addressed in AC 20 - 115D , AC 00 - 69 , or were removed .

6. Software Topics Covered i n This Order .

a. This order assumes that RTCA/DO - 178B /C is the means of compliance proposed by the applicant for software approval . If the applicant proposes other means, additional policy and FAA guidance may be needed on a project - by - project basis.

b. This order addresses software - related topics and is supplemental to RTCA/DO - 178B/C.

Guidelines in the following areas are addressed: (1) The software review process (chapter 2) ; and (2) Softwar e conformity inspections (chapter 4).

1 - 2 3 /29/1 8 8110.49A 7. Definitions. For purposes of this order, the following definitions apply: a. Certification authority is the aviation authority that accepts and/or approves software life cycle data.

b. Certification credit is the acceptanc e by the certification authority that a software process, software product, or demonstration satisfies a certification requirement (see RTCA/DO - 178B/C, Glossary).

c. Original certification project is the first use of the software life cycle data in a completed certification project.

d. Review is the act of inspecting or examining software life cycle data, software project progress and records, and other evidence to assess compliance with RTCA/DO - 178B/ C objectives. Review is an encompassing term and may consist of a combination of reading documents, interviewing project personnel, witnessing activities, sampling data, and participating in briefings. A review may be conducted at your own desk, at an ap plicant’s facility, or at an applicant’s supplier’s facility.

e. Sampling is selecting a representative set of software life cycle data for inspection or analysis. The purpose is to determine the compliance of all software life cycle data developed up to tha t point in time in the project. Sampling is the primary means of assessing the compliance of the software processes and data. Examples of sampling may include the following: (1) Inspecting the traceability from system requirements to software requirements to software design to source code to object code to test cases and procedures to test results.

(2) Reviewing analyses used to determine RTCA/DO - 178B/C objective compliance (for example, timing analysis).

(3) Examining the structural coverage of code modules.

(4) Examini ng software quality assurance (SQA) records and configuration management records.

f. Software is computer programs and, possibly, associated documentation and data pertaining to the operation of a computer system (see RTCA/DO - 178B/C, Glossary).

g. Software Confi guration Index (SCI) identifies the configuration of the software product. It can contain one configuration item or a set of configuration items (see RTCA/DO - 178B/C, Section 11.16).

h. Software library is a controlled repository of software and related data and documents designed to aid in software development, use, or modification (see RTCA/DO - 178B/C, Glossary).

i. Software life cycle data are data produced during the software life cycle to plan, direct, explain, define, record, or provide evidence of activitie s (see RTCA/DO - 178B/C, Section 11.0).

1 - 3 3 /29/1 8 8110.49A Sections 11.1 through 11.20 of RTCA/DO - 178B and Sections 11.1 through 11.22 of RTCA/DO 178C describe different kinds of software life cycle data.

j. Software Life Cycle Environment Configuration Index identifies the conf iguration of the software life cycle environment. It is written to aid reproduction of the hardware and software life cycle environment (see RTCA/DO - 178B/C, Section 11.15).

k. Software plans and standards are a set of data that directs the software developme nt processes and integral processes (see RTCA/DO - 178B/C, Sections 4.0 and 11.1 through 11.8).

l. Software tool is a computer program used to help develop, test, analyze, produce, or modify another program or its documentation (see RTCA/DO - 178B/C, Glossary).

m. T est for certification credit is system certification test conducted under a FAA - approved test plan for the purpose of showing compliance to the regulations.

n. Tool qualification is the process necessary to obtain certification credit for a software tool with in the context of a specific airborne system (see RTCA/DO - 178B/C, Section 12.2 and Glossary).

8. Acronyms. The following is a list of acronyms used in this order: Acronym Explanation Advisory Circular AC AIR Aircraft Certification Service ASE Aviation Safety Engineer ASI Aviation Safety Inspector ASTC Amended Supplemental Type Certificate Amended Type Certificate ATC Code of Federal Regulations CFR CRC Cyclic Redundancy Check FAA Federal Aviation Administration MIDO Manufacturing Inspection District Office Manufacturing Inspection Satellite Office MISO SAS Software Accomplishment Summary SCI Software Configuration Index SCMP Software Configuration Management Plan SQA Software Quality Assurance Supplemental Type Certificate STC TC Type Certificate TIA Type Inspection Authorization TSO Technical Standard Order TSR Total Score Result 1 - 4 3 /29/1 8 8110.49A 9. Records Management. Refer to Orders 0000.1 G and 1350.14 B or your office Records Management Officer (RMO)/Directives Management Officer (DMO) for guidance regarding retention or disposition of records.

10. Suggestions for Improvement. If you find deficiencies, a need for clarification, or want to suggest improvements on this order, send a copy of FAA Form 1320 - 19, Directive Feedback Information, to th e Aircraft Certification Service, Attention: Directives Management Officer at 9 - AWA - AVS - AIR - DMO@faa.gov , for consideration. If you urgently need an interpretation, you may contact the Systems Integration Se ction at 202 - 267 - 1575 for guidance. You should also use the FAA Form 1320 - 19 as a follow - up to verbal conversation. FAA Form 1320 - 19 may be found in Appendix B and electronically at https:/ /employees.faa.gov/tools_resources/forms/ .

11. Where to Find this Order. You can find this order at http://www.faa.gov/regulations_policies/orders_notices and on the FAA Regulatory and Guidance Library (RGL) website at http://rgl.faa.gov .

1 - 5

3 /29/1 8 8110.49A Chapter 2. Software Review Process 1. General.

a. Section 9 of RTCA /DO - 178B/C describes the certification liaison process. This process is the vehicle to establish communication and understanding between the applicant and the certification authority. Sections 9.2 and 10.3 of RTCA/DO - 178B/C state that the certification a uthority may review the software life cycle processes and data to assess compliance to RTCA/DO - 178B/C. This chapter does not change the intent of RTCA/DO - 178B/C.

b. Although desk reviews may be used to successfully review software, on - site reviews have the a dvantages of access to software personnel, to all automation, and to test setup. Both on - site and desk reviews may be delegated to properly authorized designees. For on - site reviews, the certification authority should include the following practical arra ngements with the software developer: (1) Agreement on the scope of review(s) that will be conducted.

(2) Agreement on date(s) and location(s) of the review(s).

(3) Identification of the certification authority’s personnel involved.

(4) Identification of any designees inv olved.

(5) Development of the agenda(s) and expectations.

(6) Listing of software data to be made available (both before and at the review(s)).

(7) Clarification of procedures to be used.

(8) Identification of any required resources.

(9) Specification of date(s) and means for communicating review results (may include corrective actions and other post - review activities).

2. Objectives of the Software Review Process.

a. The c ertification authority may review the software life cycle processes and associated data to obtain assurance tha t a software product submitted as part of a certification application complies with the certification basis and satisfies the applicable objectives of RTCA/DO - 178B/C. The software review process assists both the certification authority and the applicant t o determine if a particular project will meet the certification basis, applicable guidance, and RTCA/DO - 178B/C objectives by providing: (1) Timely technical interpretation of the certification basis, RTCA/DO - 178B/C objectives, FAA guidance, issue papers, and o ther applicable certification requirements.

2 - 1 3 /29/1 8 8110.49A (2) Visibility into the implementation compliance and the applicable data.

(3) Objective evidence that the software project adheres to its approved software plans and procedures.

(4) The opportunity for the certification aut hority to monitor designee activities.

b. The level of certification authority involvement in a software project should be determined and documented as soon as possible in the project life cycle. Appendix A provides examples that may be used to determine the level of involvement. The scope and number of software reviews, if any, will depend on several factors including: (1) Software level(s), as determined by a system safety assessment.

(2) Product attributes (such as size, complexity, system functionality or novelt y, and software design).

(3) Use of new technologies or unusual design features.

(4) Proposals for novel software methods or life cycle model(s).

(5) Applicant’s experience in satisfying the objectives of RTCA/DO - 178B/C.

(6) Availability, experience, and authorization of designees.

(7) Issues associated with Section 12 of RTCA/DO - 178B/C in the project.

(8) Applicability of issue papers for software - specific aspects of the certification project 2 - 2

3 /29/1 8 8110.49A Chapter 3. [Reserved] 3 - 1

3 /29/1 8 8110.49A Chapter 4. Software Conformity Inspection 1. General . This chapter describes the software conformity inspection process. This process applies to TC, STC, ATC, ASTC, and TSO authorization projects. This chapter is based on FAA Order 8110.4B and RTCA/DO - 178B. While RTCA/DO - 178B is recognized by AC 20 - 115B as a means, but not the only means, to secure FAA approval of the digital computer software, it is used here because it is the typical means of compliance used by applicants integrating airborne software. If another means of compliance other than RTCA/DO - 178B is used, the conformity concepts of this chapter should still apply.

2. Discussion . A conformity inspection is required to determine that the applicant complies with 14 CFR § 21.33(b) and that the product and components conform to approved type design.

For software, type design consists of, as a minimum, Software Requirements Data, Design Description, Source Code, Executable Object Code, Software Configuration Index, and the Software Accomplishment Summary (see RTCA/DO - 178B, Section 9.4). Determinatio n of an applicant’s compliance to software type design is largely assessed through ASE or DER (if authorized) reviews throughout the software development life cycle; the details of which are presented in chapter 2 of this order. However, there are instanc es where the state of the software must be reviewed and documented before issuance of TC, STC, ATC, ASTC, or TSO authorization (specifically, test acceptance and installation). Accordingly, there are two means for achieving this: (1) software part conform ity inspection, and (2) software installation conformity inspection.

3. Software Part Conformity Inspection. The conformity of the test article, test setup, test procedures used, and the validity of the test results should be established for each test condu cted for certification credit. Test for certification credit is defined in this chapter as system certification test conducted under an FAA - approved test plan for the purpose of showing compliance to the regulations. The FAA - approved test plan is the tes t plan approved before conducting an official FAA ground or flight test. It is not the Software Verification Plan referenced in RTCA/DO - 178B. Examples of tests conducted to satisfy FAA certification credit are RTCA/DO - 160D environmental qualification tes ts, system functional tests, systems integration tests, aircraft ground functional tests, and aircraft Type Inspection Authorization Tests (TIA) flight tests.

a. The ASE should perform the following tasks: (1) Establish that the software baseline complies to its type design and released software plans by conducting FAA desk and/or on - site reviews (see chapter 2 of this order); or establish that the software DER (if delegated) has approved the baseline software by submitting a FAA Form 8110 - 3, “Statement of Complia nce with the Federal Aviation Regulations.” The DER should state in Form 8110 - 3 that the “purpose of Form 8110 - 3 is to approve the software baseline for the purposes of conducting FAA testing for certification credit.” Note: In some cases, special purpose softw are is used for environmental qualification testing. When this is the case, the manufacturer must verify, validate, and control the configuration of the special purpose test software. The test software should be included as part of the test setup conform ity conducted before the qualification testing.

4 - 1 3 /29/1 8 8110.49A (2) Establish that the test configuration of the software to be installed in the Line Replaceable Unit complies with its software test baseline.

(3) Establish that all software artifacts associated with the test base line are properly identified, under configuration control, and reflect the current state of the software under test.

(4) Establish that any software development tools or software verification tools that require qualification have been qualified. However, if t he tool qualification activities are not completed at the time of conformity, the tools and supporting data should have their configuration documented.

(5) Initiate a FAA Form 8120 - 10, Request for Conformity, and submit it to the MIDO/MISO, providing instructi ons for the ASI to perform the following: (a) Verify that the proper build and load file(s) was/were removed from the software configuration management (SCM) library.

(b) Verify that approved build and load instructions are followed during the software build and l oad process.

(c) Verify that any data integrity checks and software part numbers (including version numbers) are verified in the Line Replacement Unit.

(d) Verify that the test setup conforms to the test setup configuration identified in the approved engineering t est plan.

(6) Establish that the procedure used for retention, archive, and retrieval of the software life cycle data is compliant with the approved SCM plan.

b. The ASI should perform those tasks mentioned in paragraph 4 - 3a(5) above and as identified on the Form 8120 - 10.

c. The software part conformity inspection should be successfully conducted before requesting a software installation conformity inspection.

4. Software Installation Conformity Inspection. A software installation conformity inspection is required anytime an FAA aircraft - level ground or certification flight test is performed, such as tests conducted per the TIA. The main objectives are to show that: a. An approved, controlled version of the s oftware is loaded successfully into the target system in conformance with approved system installation procedures and/or software loading procedures, and b. The correct version for that system was loaded and will successfully initialize.

c. The ASE should ensure : (1) A prior software part conformity inspection was successfully completed.

4 - 2 3 /29/1 8 8110.49A (2) Load procedures have been approved.

(3) A FAA Form 8120 - 10, Request for Conformity, or FAA Form 8110 - 1, Type Inspection Authorization (TIA), is initiated and contains the software part n umber and/or version number for which an installation conformity inspection is being requested. The software part number and/or version number should be identifiable, under configuration control, reproducible, and documented in the SCI or similar configur ation documentation. The request should also include any actions/activities to be verified by the ASI including: (a) Verification that the correct software version has been loaded into the system and that the correct system hardware (part numbers and serial n umbers) has been installed on the aircraft.

(b) Verification that the loading procedure(s) ensures the correct software part number (and version number) is loaded into the correct system hardware components (serial numbers and part numbers). An error indicati on should result anytime that the software loading procedure or ground support equipment detects a mismatch of part and version numbers or an unsuccessful load. The installation conformity inspection should determine that the manufacturer’s loading proced ure(s) are followed and that the software load initializes correctly.

Mismatches should be identified and documented.

d. The ASI should perform the software installation conformity inspection addressed in the FAA Form 8120 - 10, or FAA TIA Form 8110 - 1 (see ite m 4 - 4c (3) of this chapter) by one of two methods: (1) By physically witnessing the successful loading of the correct software part number and version into the actual system (that is, actual part number and serial number) installed on the aircraft or to be inst alled on the aircraft. Successful load may be determined by witnessing that an integrity check was used to verify the software load (for example, comparison of cyclic redundancy checks (CRC)), and by witnessing that the software successfully executed the initialization procedure. The software loading process must be done in accordance with the software load procedures reviewed and approved by the ASE.

(2) By obtaining the manufacturing inspection records that document the results of the actual software loadin g. These records should include aircraft identification information, system hardware part numbers and serial numbers, and software part numbers and version number, as applicable. The records provided should identify the hardware unit part number and seri al number information so that the ASI (or designee, if delegated) can trace it to the system installed on the aircraft. The records provided should also show the software part number that was loaded into the system hardware. The records should indicate w hen and how the software was loaded and that the loading and initialization process was successful.

e. The software installation conformity inspection ensures that the system(s) installed on the aircraft and the software loaded into the system(s) for the purp ose of conducting aircraft - level testing conforms to the FAA - approved type design data.

5. Summary. The purpose of a conformity inspection is to ensure that the product built (hardware and software) conforms to the type design. The two types of software co nformity 4 - 3 3 /29/1 8 8110.49A inspections addressed in this chapter are “software part conformity inspections” and “software installation conformity inspections.” The responsibilities for ASEs and ASIs are identified for each of the two types of software conformity inspection s addressed in this chapter. Software part conformity inspections and software installation conformity inspections are required whenever an applicant is to conduct laboratory system/hardware testing for certification credit as defined in paragraph 4 - 3, an d during the installation of the system with the embedded software for the purpose of conducting aircraft - level ground and/or flight testing. The purpose of the aforementioned software conformity inspections is to ensure: a. T he configuration of the unit und er test reflects the correct hardware and software configuration that was approved for the given test being conducted for FAA certification credit.

b. T he configuration of the unit under test is well documented should there be any changes to the hardware and/ or software after the tests have already been conducted.

c. T he systems installed on the aircraft and the software loaded into the installed systems for the purpose of conducting aircraft - level testing conforms to the FAA - approved type design.

d. T he final software and hardware configuration product baseline presented for certification conforms to the type design .

4 - 4 3 /29/1 8 8110.49A Appendix A Appendix A. Level of Involvement Worksheets Appendix A contains three worksheets that may be used to help the certification authority or de signee determine an appropriate level of involvement in software projects. The worksheets are provided as examples only ; may contain criteria that are not applicable to all projects; and their use, individually or in combination, is not mandatory. Worksh eet 1 indicates a level of involvement based on the software level of the project. Worksheet 2 allows for additional refinement of involvement based on more specific criteria. Worksheet 3 uses the total score result from Worksheet 2 to indicate a level o f involvement.

Worksheet 1: Level of Involvement Based on Software Level RTCA/DO - 178B/C Software Level Level of Involvement D LOW C LOW or MEDIUM B MEDIUM or HIGH A MEDIUM or HIGH A - 1 3 /29/1 8 8110.49A Appendix A Worksheet 2: Level of Involvement Based on Other Relevant Project Criteria Criteria Scale MIN . MAX . Score 1. Applicant/Developer Software Certification Experience 1.1 Experience with civil Scale: 0 5 10 aircraft or engine # projects: 0 3 - 5 6+ certification.

1.2 Experience with Scale: 0 5 10 RTCA/DO - 178B/C. # projects: 0 2 - 4 5+ 1.3 Experience with Scale: 0 3 5 RTCA/DO - 178 or # projects: 0 4 - 6 7+ RTCA/DO - 178A.

1.4 Experience with other Scale: 0 2 4 software standards # projects: 0 4 - 6 7+ (other than RTCA/DO - 178 [ ]).

2. Applicant/Developer Demonstrated Software Development Capability 2.1 Ability to consistently Scale: 0 5 10 produce RTCA/DO - Ability: Low Med High 178B/C software products.

2.2 Cooperation, openness, Scale: 0 5 10 and resource Ability: Low Med High commitments.

2.3 Ability to manage Scale: 0 5 10 software development Ability: Low Med High and sub - contractors.

2.4 Capability assessments Scale: 0 2 4 (for example, Software Ability: Low Med High Engineering Institute Capability Maturity Model, ISO 9001 [] ).

2.5 Development team Scale: 0 5 10 average based on Ability: < 2 yrs 2 - 4 yrs > 4 yrs relevant software development experience.

3. Applicant/Developer Software Service History 3.1 Incidents of software - Scale: 0 5 10 related problems (as a Incidents: > 25% > 10% None % of affected products).

3.2 Company Scale: 0 5 10 management’s support Quality: Low Med High of designees.

3.3 Company software Scale: 0 5 10 quality assurance Quality: Low Med High organization and configuration management process.

A - 2 3 /29/1 8 8110.49A Appendix A Criteria Scale MIN . MAX . Score 3.4 Company stability and Scale: 0 3 6 commitment to safety. Stability: Low Med High 3.5 Success of past Scale: 0 3 6 company certification Success: None > 50% All efforts.

4. The Current System and Software Application 4.1 Complexity of the Scale: 0 5 10 system architecture, Complex: High Med Low functions, and interfaces.

4.2 Complexity and size of Scale: 0 5 10 the software and safety Complex: High Med Low features.

4.3 Novelty of design and Scale: 0 5 10 use of new technology. Newness: Much Some None 4.4 Software development Scale: 0 3 6 and verification Environ: None Older Modern environment.

4.5 Use of alternative Scale: 0 3 6 methods or additional Standard: Much Little None considerations.

5. Designee Capabilities 5.1 Experience of Scale: 0 5 10 designee(s) with Projects: < 5 5 - 10 > 10 RTCA/DO - 178B/C.

5.2 Designee authority, Scale: 0 5 10 autonomy, and Autonomy: None Self - starter Outgoing independence.

5.3 Designee cooperation, Scale: 0 5 10 Effectiveness: Non - Responsive Responsive Cooperative/Open openness, and issue resolution effectiveness.

5.4 Relevance of assigned Scale: 0 5 10 designees’ experience. Related: None Somewhat Exact 5.5 Designees’ current Scale: 0 5 10 workload. Workload: High Medium Low 5.6 Experience of Scale: 0 3 5 designees with other Projects: < 5 5 - 10 > 10 software standards (other than RTCA/DO - 178[]).

Total Score Result (TSR): ______ A - 3 3 /29/1 8 8110.49A Appendix A Worksheet 3: Level of Involvement Combining Results of Worksheet 2 with Software Level Total Score Result Software Software Software Software (TSR) Level A Level B Level C Level D TSR < 80 HIGH HIGH MEDIUM LOW 80 < TSR < 130 HIGH MEDIUM MEDIUM LOW 130 < TSR MEDIUM MEDIUM LOW LOW A - 4 3 /29/1 8 8110.49A Appendix B Appendix B. Directive Feedback Information Directive Feedback Information Please submit any written comments or recommendation for improving this directive, or suggest new items or subjects to be added to it. Also, if you find an error, please tell us about it.

Subject: Order 8110.49 A, Software Approval Guidelines To: 9 - AWA - AVS - AIR - DMO@faa.gov or complete the form online at https://ksn2.faa.gov/avs/dfs/Pages/Home.aspx Please check all appropriate line items: An error (procedural or typograp hical) has been noted in paragraph _______ on page _______ .

Recommend paragraph _______ on page _______ be changed as follows: In a future change to this AC, please cover the following subject: (Briefly describe what you want added.)

Other comments: I would like to discuss the above. Please contact me.

Submitted by: _________________________ _________ Date: __________________ Telephone Number: __________________ Routing Symbol: _________________ FAA Form 1320 - 19 (10 - 98) B - 1